We have a project with a few release branches and a trunk. Lately we’ve been adding bugfixes and new features to the release branch, while doing simultaneous infrastructure development on the trunk. This has caused us some problems.
Today I was told to merge changes from branch to trunk, using HEAD as starting/end revisions. It generated a dozen conflicts, which I resolved mostly by accepting the working copy of the trunk. After this was done, I found some scrambled code and some variables that didn’t belong in functions.
In addition to giving me a headache, this makes me re-think the way I approached merging. Is it a better practice to merge from a RECENT starting revision, as opposed to the origin of the branch? I actually did it this way first, and it didn’t result in any scrambled code or misplaced variables.
2
It generated a dozen conflicts, which I resolved mostly by accepting the working copy of the trunk.
Well, this seemed to be one cause of the problem. Check merge conflicts very carefully and make sure you resolve them by manual editing, not by (perhaps blindly?) accepting them.
Especially with SVN (but I guess even with DVCS) when doing structural changes on one branch (with cross-cutting nature, like renaming functions or classes, changes file or library structure etc.), it is better not to hold these changes back from other branches for a long period. Better merge these changes to the other branches as soon as possible.
When I understood you correctly, you could not do this here so easily because you did not want to risk the structural changes in the trunk to destabilize the relase branch. In this case it would have probably been better to merge every bug fix or new feature from the release branch immediately to the trunk once the bug fix or new feature was done. This at least lets you handle the merge conflicts one-by-one, and its easier to anticipate how a bug fix from the release branch maps to the structural changed code of the trunk when this is done immediately.
2