CVS merge bit me
Posted by Ronnie Holm on September 24th, 2006
I’m currently managing the merge operations for a CVS repository with a branch layout looking partly as follows:
At some point in the past HEAD branched into B1, which subsequently branched into B1.1. Then development on B1 completed and it was merged back into HEAD so a release branch B2 could be created. B1.1, however, kept living its separate life for a while, because the features added aren’t to be released until with release branch B5. This also goes for the changes made to B3, so it makes sense for B1.1 to be merged into B3.
As a result, I just spend a few hours on tracking down a merge issue resulting from this merge, because a change made in B1 wasn’t present in B3 after B1.1 was merged into this branch. I finally figured out why: suppose a line is removed in B1 before the spin-off of B1.1. After that the very same line is added back in. Now when B1.1 is merged into B3, the line is removed again. There is no merge conflict at this point, because from CVS’ point of view it’s a clean merge.
It seems obvious what happened when looking at the diagram, but when you’re working with a large repository with lots of modified files and you’re merging code not written by yourself, this sort of indirect change propagation may inevitably bite you as well.
