mergeinfo between svn copied branches and merges

[Z W <mp...@gmail.com>]

Hi All


we have branchA

we svn copy branchA to produce branchB

branches A and B continues development and checkins

branchA is merged to branch B continuously

branchA finishes, tagged

we then svn copy branchA to produce branchC

we like to continue branchC merging to branchB

we hear u clearly that the merge info are copied between branches

we performed svn mergeinfo merged on branchB working copy

with branchA

we could see the correct list of merged rev numbers

we performed svn mergeinfo eligible on branchB working copy with branch A;
we see correct list of eligigle rev numbers

we learn that these numbers are used by SVN to calculate what needs to be
merged from branchB to branchA (-reintegrate)

we performed svn mergeinfo merged on branchB working copy with branchC

we see a new list (not including list of merged rev numbers from branchA)

we learn that if we reintegrate from branchB to branchC, because those list
of merged rev numbers from branchA are not there, SVN would not know those
rev numbers changes already exist in branchC

so SVN would try to reintegrate those list of merged rev numbers from
branchA on branchC

thus causing tree conflict.

Would u agree ?


How do we best recover this situation such that

1- we dont lose mergeinfo information from branchA when trying to
reintegrate from branchB to branchC

2- no tree conflicts when performing reintegrate from branchB to branchC


Thank you.

RE: mergeinfo between svn copied branches and merges

[Andrew Reedick <An...@cbeyond.net>]

> From: Z W [mailto:mpc8250@gmail.com] 
> Sent: Wednesday, May 08, 2013 6:49 AM
> To: Andrew Reedick
> Cc: users@subversion.apache.org
> Subject: Re: mergeinfo between svn copied branches and merges
>
> In this case, all you should have to do is:
> a) merge branchC UP to branchB
> b) merge --reintegrate branchB DOWN to branchC.
> Step a) will pick up any branchA changes (because all of branchA is a subset of branchC.)
>
> >> This strategy is still new to us.
> We're not sure what the intermediate steps are trying to accomplish, esp the merge up and down parts.
> What is the exact syntax (as an example) for (a) and (b) ?

a) merge branchC UP to branchB
	cd branchB_workspace (or create a brand new, clean workspace)
	svn status (check for existing changes)
	svn update (If your workspace is not up to date, svn merge will complain.)
	svn merge svn://.../branchC
	resolve any conflicts
	svn ci

b) merge --reintegrate branchB DOWN to branchC.
	cd branchC_workspace (or checkout a clean workspace)
	svn status
	svn update
	Notify folks to not check into branchB, or simply lock branchB (since we will need to delete branchB)
	svn merge --reintegrate svn://.../branchB
	resolve any conflicts
	svn ci 
	svn log -l 3 svn://.../branchB (Since we're going to delete branchB, make sure that no one checked into branchB after your merge)
	svn rm svn://.../branchB
	svn copy svn://.../branchC@1234 svn://.../branchB  (recreate the branchB if it is still needed.)
		where 1234 is either the HEAD of branchC or the merge point on branchC.  It's up to you.

	This is covered in the svn book:  http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

UP/DOWN:
You merge UP to a child branch that was created from a parent branch.  You merge "back DOWN" to a parent branch from a child branch.  "UP" and "DOWN" are just semantics to help you keep things straight due to the need to run --reintegrate.  Once svn 1.8 comes out, you shouldn't have to worry about up, down, and --reintegrate anymore.

>> we svn copy branchA to produce branchB
In this case, branchA is the parent, and branchB is the child, so you merge UP from A to B, and DOWN (via --reintegrate) from B back to A.  In the example given in the svn book, branchA would be the "calc-trunk" and branchB would be "my-calc-branch".

>> we then svn copy branchA to produce branchC
Since branchC was created from branchA, branchC would still be the "parent" of branchB.  Merge UP to branchB, merge DOWN to branchC.


Of course, this is Subversion, and merge tracking wasn't part of the original design specs, so there's always the chance of something odd happening...

Branching and merging:  http://svnbook.red-bean.com/en/1.7/svn.branchmerge.html

Re: mergeinfo between svn copied branches and merges

[Z W <mp...@gmail.com>]

Hi Andrew

thanks for responding.


On Tue, May 7, 2013 at 2:14 PM, Andrew Reedick
<An...@cbeyond.net>wrote:

>
> > From: Z W [mailto:mpc8250@gmail.com]
> > Sent: Tuesday, May 07, 2013 11:53 AM
> > To: users@subversion.apache.org
> > Subject: mergeinfo between svn copied branches and merges
> >
> > we have branchA
> > we svn copy branchA to produce branchB
> > branches A and B continues development and checkins
> > branchA is merged to branch B continuously
> > branchA finishes, tagged
> > we then svn copy branchA to produce branchC
> > we like to continue branchC merging to branchB
> > we hear u clearly that the merge info are copied between branches
> > we performed svn mergeinfo merged on branchB working copy
> > with branchA
> > we could see the correct list of merged rev numbers
> > we performed svn mergeinfo eligible on branchB working copy with branch
> A; we see correct list of eligigle rev numbers
> > we learn that these numbers are used by SVN to calculate what needs to
> be merged from branchB to branchA (-reintegrate)
> > we performed svn mergeinfo merged on branchB working copy with branchC
> > we see a new list (not including list of merged rev numbers from branchA)
>
>
> > we learn that if we reintegrate from branchB to branchC, because those
> list of merged rev numbers from branchA are not there, SVN would not know
> those rev numbers changes already exist in branchC
> > so SVN would try to reintegrate those list of merged rev numbers from
> branchA on branchC
> > thus causing tree conflict.
>
> Svn will implicitly know about the rev numbers from branchA because
> branchA is a subset of branchC.  Go here
> http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.nomergedataand read "Natural History and Implicit Mergeinfo".
>
> In this case, all you should have to do is:
> a) merge branchC UP to branchB
> b) merge --reintegrate branchB DOWN to branchC.
> Step a) will pick up any branchA changes (because all of branchA is a
> subset of branchC.)
>

>> This strategy is still new to us.
We're not sure what the intermediate steps are trying to accomplish, esp
the merge up and down parts.
What is the exact syntax (as an example) for (a) and (b) ?

Sincerely


>
> If you did additional work on branchA *after* creating branchC, then you
> would need to:
> a) merge branchA UP to branchB,
> b) merge branchC UP to branchB,
> c) merge --reintegrate branchB down to branchC.
>
>
>

RE: mergeinfo between svn copied branches and merges

[Andrew Reedick <An...@cbeyond.net>]

> From: Z W [mailto:mpc8250@gmail.com] 
> Sent: Tuesday, May 07, 2013 11:53 AM
> To: users@subversion.apache.org
> Subject: mergeinfo between svn copied branches and merges
>
> we have branchA
> we svn copy branchA to produce branchB
> branches A and B continues development and checkins
> branchA is merged to branch B continuously
> branchA finishes, tagged
> we then svn copy branchA to produce branchC
> we like to continue branchC merging to branchB
> we hear u clearly that the merge info are copied between branches
> we performed svn mergeinfo merged on branchB working copy
> with branchA
> we could see the correct list of merged rev numbers
> we performed svn mergeinfo eligible on branchB working copy with branch A; we see correct list of eligigle rev numbers
> we learn that these numbers are used by SVN to calculate what needs to be merged from branchB to branchA (-reintegrate)
> we performed svn mergeinfo merged on branchB working copy with branchC
> we see a new list (not including list of merged rev numbers from branchA)


> we learn that if we reintegrate from branchB to branchC, because those list of merged rev numbers from branchA are not there, SVN would not know those rev numbers changes already exist in branchC
> so SVN would try to reintegrate those list of merged rev numbers from branchA on branchC
> thus causing tree conflict.

Svn will implicitly know about the rev numbers from branchA because branchA is a subset of branchC.  Go here http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.nomergedata and read "Natural History and Implicit Mergeinfo".

In this case, all you should have to do is:
a) merge branchC UP to branchB
b) merge --reintegrate branchB DOWN to branchC.
Step a) will pick up any branchA changes (because all of branchA is a subset of branchC.)

If you did additional work on branchA *after* creating branchC, then you would need to:
a) merge branchA UP to branchB,
b) merge branchC UP to branchB,
c) merge --reintegrate branchB down to branchC.