Tips for manual merge of diverged code

Question

I am fairly used to using svn for branching and merging, normally this works fine. However one component was worked on in two branches and basically took the component in different directions, so automatic merge won't work and using beyond compare shows the files as mostly different.

I have tried to stitch together some of the files, but the results, even if they work, are fairly horrific.

I am tempted to say to the business that this just can't be done. I can see this frustrating them as they have module + feature A working and module + feature B working but module + feature A + feature B just doesn’t make sense as it stands. For example feature A may remove something that was a key component in feature B.

Is there a way to try to merge such code? Or is module + A + B really module + C?

We did see this coming, but feature A was needed on a shorter time scale than feature B which was part of a long running project. Are there ways to work to avoid this happening? Or are their ways to structure the code so that both features will fit together nicely?

Answer 1

What you're talking about is essentially trying to rebase one of the branches. There is support for this in some DVCSs but I'm not aware of any support for this kind of thing in SVN.

Your best bet is to pick one of the branches (the one that is most important to have now) and merge it in to the main line which should be fairly straight forward. In the other branch you will need to pull the changes from trunk and reconcile the differences, given the situation you described, this will almost certainly not be automatic and you might have to spend some serious time thinking about how to implement this branches features on top of the one merged into the main line, but that's the cost of parallel development: things change.

How do you avoid this in the future? Frequent integration.

If you have two teams that are each given codebase A and they go and work on different features for 6 months, the integration is going to very painful as each will have made assumptions about A that the other team has changed. On the other hand, with weekly or monthly integration builds, each team should be substantially more aware about which changes the other is making and final integration should be much easier.

This is why open source projects often oppose huge patches, they get out of date startlingly fast and nobody really has the time to review them properly. On the other hand, if you take the same contribution and break it up into a number of small digestible parts that stand alone, your contribution is much more likely to be A) accepted and B) reviewed properly so that it doesn't result in an endless stream of defects.

Answer 2

Take a single file, say src1.c. You can construct a diamond diagram describing the merge this way:

   Original src1.c
        /       \
       /         \
      /           \
   b1 src1.c     b2 src1.c
      \            /
       \          /
        \        /
      \      /
     merged src1.c

Where b1 means the first branch version and b2 means the second branch version. You can compare parallel diffs (say the one between the merged source and b2 version, and b1 and the original). This may help.