Why I think Merging Source Code sucks

Recently I was involved in a pretty large project to do a full and complete source code merge of 2 branches into one. We used TFS in the project and that was a first for me. So perhaps my experience was sub-optimal due to my lack of understanding of TFS but here are my thoughs on it anyway:

  • For some reason the branch relationships that should have existed between all the files of the two code branches were broken for some of the files. Even when we did a baseless Merge these relations remaind broken even though the manual says that they should be fixed after a baseless merge.

  • Using the Auto Merge “feature” reintroduced some defects that were fixed in one branch. Clearly this is not a “featue” you want to use all that often.

  • A Merge cannot cope with refactoring. Basically you are on your own when you refactor too much of you code and the text-based compare can’t match up the pieces of code that are the same, because they’re too far apart.

  • Merging of generated assets (workflow, dataset, etc.) is a disaster. You would normally just merge the model and let the tool generate the code for the new model. But manually (or automatically) merging the “model” is no easy task.

  • Resolving conflicts in project and solution files is also problematic. Most of the time we just made sure that all the changes of both branches were in the output and later sorted out the deleted files and stuff. Problem is that you cannot see the context of these files (associated files etc).

  • Resolving conflicts in normal source code (C# in this case) was not a walk in the park either. The 3-view comparer tool you’ll get to resolve these conflicts has no syntax collering. Its basically a scitzofranic notepad.

I think the problem with resolving conflicts is that it is a text-based operation (at least it seems to be). The auto-merge feature has no clue what it is merging and therefor it is no wonder it makes a mess of you source files. What you need is a specific conflict resolver for eacht type of file (with Text as the default fallback). So If I had a DataSet resolver it would know that this xml schema was in fact a DataSet and it could make (or propose) educated changes to the output. If you’d had these resolvers with builtin knowledge of what they are merging, I think the result would improve drastically. And it would make me a happy camper again. Up until that day, code merges are a pain for me.

What is your experience with merging code trees?

  1. One thought on “Why I think Merging Source Code sucks

    Merging branches which both have changed dramatically are very hard to do if not impossible.

    Linus Torvalds says that changes in the linux kernel etc. will be done by a small team of developers. Only when the change if very well understood then it gets committed. The way that GIT works is that you first create your own personal branch to work on and when you are ready then you ask the maintainer of the /trunk branch to import that changeset. If the maintainer sees that the change conflicts too much because the main trunk has changed much because of – for example – refactoring then he just says that it will not import the change set as it is done on out dates source files. The only way to do a proper change is to add the change on an updated local branch and then asking the trunk maintainer for importing the change.

    After reading that I use the same philosophy. I won’t merge large code changes on out of date branches. I just delegate it to the developer that implemented the RFC to code it again as too much has changed.

    Doing the merging myself is error prone and would take too much time! It would often be faster to just code the RFC myself 🙂

    This immediately brings me to the following MUST versioning/code repository rules:
    * Update reqularly (at least once a day)
    * Commit often (commit when you have complete a small logical part)
    * Changes must NEVER be done on the /trunk directly. First on a seperate branch, then reviewed and changed until satisfied and then be merged in to the main trunk.

    Managers MUST check this or even must be notified when a developer has not committed for a while because that would indicate a possible problem.

Comments are closed.