0

We use SVN 1.6 We like to perform code merging between branches and we are in a dilemma situation.

Branch A exists
Folks making code changes on Branch A
Branch B created from branch A
Folks making code changes on both branches A and B
Branch A sync code merging to Branch B
After some time
Branch C created from branch A
Branch A continues sync code merging to Branch B (for a short time)
Folks making code changes on Branch C Folks stop code changes on Branch A and branch "frozen", no more ci
Folks making code changes on Branch B
Branch C sync code merging to Branch B
Folks making code changes on Branches B and C
After some long period of time

Now Dilemma: We like to merge Branch B to Branch C

Because Branch B is from Branch A and not Branch C, we could not apply --reintegrate option for code merging from B to C because they don't share common ancestry

What's the least risky way to merge (without the --reintegrate option) to prevent "double merges/duplicated code" of (C in B) into branch C ?

Micha
  • 5,117
  • 8
  • 34
  • 47
chz
  • 355
  • 1
  • 7
  • 21
  • Can you use "merge a range of revisions". Tortoise provides such a option, but I'm not sure if SVN 1.6 can handle this. – Micha Oct 25 '13 at 15:40

1 Answers1

0

Visualize your branch structure by a simple drawing. My understanding of your problem is: 

               C ---- C ---- C ----- C
              /        \      \
A --- A ---- A --- A    \      \      ???
 \     \      \     \    \      \
  B --- B ---- B --- B -- B ---- B ---- B

I would integrate C and B in A. If that is not an option you could do it in 3 steps / 3 series of steps:

  1. Merge all changes done in B into C but not those merged from A. Do this until you reach the last merge from A to B (which is not in C)
  2. Merge this last merge from A to B also into C
  3. Merge the remaining changes made on B (after the last merge from A), but leave out the changes included from C

I am not completely clear about your structure. If it would be

               C ---- C ---- C ----- C
              /        \      \
A --- A ---- A --- A    \      \      ???
 \     \            \    \      \
  B --- B ---- B --- B -- B ---- B ---- B

I would take the last changes from A directly into C.

BHF
  • 748
  • 7
  • 19
  • Hi BHF, thanks for responding. You diagram looks correct in my text description. So from your solution, without using --reintegrate option, that we should merge rev numbers one at a time depending on 1 of 3 steps above; is that our correct understanding ? – chz Oct 26 '13 at 00:39
  • You can do the steps as [merge a range of revisions](http://svnbook.red-bean.com/en/1.6/svn.branchmerge.advanced.html#svn.branchmerge.advanced.advancedsyntax) or as [cherrypicking](http://svnbook.red-bean.com/en/1.6/svn.branchmerge.advanced.html#svn.branchmerge.cherrypicking) of individual change sets. You reduce the risk of doing things twice, if you commit step 1 before starting step 2. Just give it a try, if it goes wrong revert your working copy and start again. Good luck. – BHF Oct 26 '13 at 05:43