Git merge conflicts in XML files

[Ramon Sistermans]

Hello all,

At one customer we are using Git for version control and our workflow more or less follows the standards of Git flow. We are doing scrum with biweekly sprints so every two weeks we develop a new number of features for the customer. At the start of every sprint we have a clean integration branch (develop) and each feature is developed by branching off into a feature branch which once tested is merged back into develop.

So far every sprint we've encountered merge conflicts when we feel these shouldn't be necessary. For example, two features developed in the same sprint require a new template to be defined in the HST, or a new document type is added to hippoecm-extension and the namespace cnd.

We are using auto export both in the CMS and the console, which more or less adds new nodes on the same line numbers every time. Say Feature1 and Feature2 are developed in parallel, then the files mentioned in the above examples will have a new entry on the same line but with different content/configuration. When merging these features back to develop, GIT will __always__ throw a merge conflict because it does not know whether Feature1 should replace Feature2 or whether Feature1 and Feature2 should be added as separate nodes in the XML files.

The merge conflicts are often easy to resolve but the complexity increases as we merge more and more features into develop. Combining merge results may become a mess and XML files can end up trying to add multiple entries of the same node or remove them implicitly.

The main problem we have with this process however is that we feel these merges should not require to be resolved manually.

We are looking for improvements in our workflow to avoid such conflicts. An alternative would be to split up XML files but the configuration may end up being verbose and more difficult to maintain.

Does anyone have the holy grail to avoiding these problems?

Thanks!

Ramon Sistermans
Consultant online

e:  ramon.si...@incentro.com
t:  +31204090444 
m:  +31615886436
w:  www.incentro.com

amsterdam office | mediahaven
moermanskkade 113  |  1013 bc   |  amsterdam

[wim.lustenhouwer]

Hey Ramon,

Are you trying to merge created content? like say some baseDocument. They generate UUID's semi-randomly, so that will create merge-conflicts. We don't create content in our develop environments (and if we do, it's done by one developer at a time). 

Your best bet is to only commit functionality and not content. (be wary of Hippo Essentials / Hippo set-up as it creates sample content).

Op vrijdag 18 september 2015 11:58:29 UTC+2 schreef Ramon Sistermans:

[Ramon Sistermans]

Hi Wim,

We do not (or rarely) commit content. We do commit configuration: mostly document types, sitemaps, (abstract)pages, templates, workspace containers and sometimes the component configuration inside these containers.

I do not recall handling a merge conflict where the UUID changes were causing the problem. These UUID's seem to update just fine.

Ramon

Ramon Sistermans
Consultant online

e:  ramon.si...@incentro.com
t:  +31204090444 
m:  +31615886436
w:  www.incentro.com

amsterdam office | mediahaven
moermanskkade 113  |  1013 bc   |  amsterdam

--
Hippo Community Group: The place for all discussions and announcements about Hippo CMS (and HST, repository etc. etc.)
 
To post to this group, send email to hippo-c...@googlegroups.com
RSS: https://groups.google.com/group/hippo-community/feed/rss_v2_0_msgs.xml?num=50
---
You received this message because you are subscribed to the Google Groups "Hippo Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hippo-communi...@googlegroups.com.
Visit this group at http://groups.google.com/group/hippo-community.
For more options, visit https://groups.google.com/d/optout.

[Ricardo Tangali]

This is a known irritation when developing hippo websites. There is no "fix" for this. I've asked this same question to hippo developers but the best answer you get is to keep the dev team small so the conflicts won't be too complex to solve.

The problem is that configuration nodes are registered in hippoecm xml. This file gets updated frequently. So you always get merge conflicts here, but they shouldn't be too hard too solve.

In the projects I've worked in, we do feature reviews. A pre-requisite is that the latest version on the develop must be integrated in the feature branch. The developer of the feature must solve the merge conflicts. After approval of the feature it can be merged with develop. This way of work limits the amount of merge conflicts at the end of the road. And the conflicts will never become too complex.

Mvg,

Ricardo

[Rick Beemsterboer]

Hi Ramon,

Like Ricardo mentions these conflicts shouldn't be too hard to resolve. Conflicts are a given when using versioning tools like SVN or Git, there's no absolute way to prevent them. 

Having said that, something thing that might help is not to rely on the autoexport feature. In the Hippo projects I've done we've never used autoexport, we've always done everything manually. This gives you more control over how you organize your xml files, which in turn causes less conflicts. For instance, if you make sure you order your nodes in a way that's logical, like alphabetically or by category, you're less likely to make changes to the same lines as your colleagues. Resulting in less conflicts.

I like to be in control and to be aware of the changes I'm making, so I'm not a big fan of the autoexport feature in general. I do think it has its place and it can come in handy in smaller projects or when you're still getting to know Hippo though.

Good luck,

Rick

--