Re: mergeinfo between svn copied branches and merges
Hi Andrew thanks for responding. On Tue, May 7, 2013 at 2:14 PM, Andrew Reedick andrew.reed...@cbeyond.netwrote: From: Z W [mailto:mpc8...@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
From: Z W [mailto:mpc8...@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
mergeinfo between svn copied branches and merges
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
From: Z W [mailto:mpc8...@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.
