0

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.

gnat
  • 21,442
  • 29
  • 112
  • 288
ktm5124
  • 101
  • 1
  • Is it possible to switch to a distributed versioning system like git or hg? If you need to merge branches, both will make your life a lot easier than SVN. – Stephen Feb 18 '14 at 05:41
  • 1
    @Stephen doubt that, his problem isn't merging its merging crap all over the place. git would complain just as much. 'generated a dozen conflicts' which he basically ignored by throwing away some diffs. – gbjbaanb Feb 18 '14 at 08:53

1 Answers1

5

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.

Doc Brown
  • 199,015
  • 33
  • 367
  • 565
  • But my problem is that SVN is applying a changeset to my trunk that is NOT unique to branch. So if I change something on trunk, but don't merge that with my branch (we freeze our branch as a production release)-- and then I merge branch to trunk, the code gets scrambled. – ktm5124 Feb 18 '14 at 15:43
  • Which makes me think our approach to merging is off, because SVN is designed to pull changes from trunk to branch, and then reintegrate branch with trunk... I think the only way to get around it is to use the 2-URL form of merging to apply only the recent changes from branch to trunk. – ktm5124 Feb 18 '14 at 15:44