Open elmarg-delta opened 1 year ago
Hi @elmarg-delta,
Thanks for the question. Let me see if I can offer some clarity.
There are a few considerations that have lead to the system we have: The first is that we need to persist the metadata files (and therefore the models) to version control so that they are always 100% in sync with the codebase, and then also benefit from the great value that version control systems bring to the table. This is why these files are there in the first place.
In terms of the many files. The problem with a single file is that there would be endless version control merge-conflicts if it was a single file. Balancing the granularity of the metadata is configurable when one sets up designers, so you can have fewer files. But this would be at the cost of increasing the probability of merge-conflicts if two developers edit the same metadata through IA.
And then in terms of the file format. We opted for XML initially because the tooling around handling merge-conflicts was better from our research. XML is definitely more bloated than say JSON, so could definitely consider making an option available where you could specify your preference. What is important is that it is human readable in case you have to handle a merge conflict at any stage. We definitely consider doing this as a feature upgrade. Do you have a format that you would prefer?
Based on this, let me know if you have any suggestions for us. We're always looking for ways to improve 🙂
Hi @elmarg-delta, if you're using BitBucket you could consider using a solution like this: https://support.atlassian.com/bitbucket-cloud/docs/exclude-files-from-pull-request-diffs/
Hi @garethbaars,
This would be amazing as an option
And then in terms of the file format. We opted for XML initially because the tooling around handling merge-conflicts was better from our research. XML is definitely more bloated than say JSON, so could definitely consider making an option available where you could specify your preference. What is important is that it is human readable in case you have to handle a merge conflict at any stage. We definitely consider doing this as a feature upgrade. Do you have a format that you would prefer?
Ask a question
We've been using Intent for a bit, but the one thing that is a bit off-putting is the massive chunks of xml files that Intent adds to the Pull Requests.
While I understand the core reasoning behind this, I'd love to find a way to eliminate from seeing this, or alternatively only have one file that contains the intent-project-configuration. From an architecture perspective xml configuration is quite bloated to begin with. Have you ever considered switching to a different format/standard?