2

I am facing a really annoying issue with SVN merge. I want to merge the trunk into a branch. Usually, it is rather simple, but this time, due to heavy changes, I had to process step-by-step and SVN does not seem to appreciate that.

Lets say I created a branch at revision A, and now the repository is at revision B. The trunk contains few sub dir, say S1, S2. To give you an idea of the complexity, B is ~1000 revisions after A, with many changes in the trunk. There were a LOT of conflicts and tree conflicts.

To process step by step, I choose to merge S1 firstly, then S2, then I hoped the merge of B will be immediate. I used the command svn merge https://myrepo/trunk/S1 myBranchWorkingCopy/S1

S1 merge was painful but successful. Same for S2.

Full of hope, I launch a dry-run of svn merge --dry-run https://myrepo/trunk myBranchWorkingCopy, waiting to see only updated properties. I was overzealous... Instead of that, EVERY conflicts (tree or text) I resolved for S1 or S2 must be resolved again...

My conclusion is

If trunk contains S1 + S2, merged(S1) + merged(S2) != merged(trunk) ?!?

Did I miss something? How can I tell SVN than every subdirs have be merged and that the trunk should be merged instantly?

Thanks

rockeye
  • 2,765
  • 2
  • 30
  • 44

1 Answers1

1

It should work by merging back to the subfolders with the --record-only flag so Subversion knows the changes are there on both sides. See the section on "Keeping a Reintegrated Branch Alive" in the Advanced Merging section of the Subversion book.

(Maybe try it out on a little sample first.)

Filip De Vos
  • 11,568
  • 1
  • 48
  • 60
  • Did not know that feature (and like it). The problem of course are the different directories where the merge were started. There is nothing to prevent you from doing that ... – mliebelt May 31 '13 at 07:46