Re: Rephrasing: question about merging branches

[Derek Robert Price]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jamie Wellnitz wrote:

|On Tue, Nov 04, 2003 at 01:27:09PM -0500, Derek Robert Price wrote:
|
|>-----BEGIN PGP SIGNED MESSAGE-----
|>Hash: SHA1
|>
|>If branch A and branch B in your example don't branch form the same
|>point on the trunk, a merge from point 2 to point 4 into the trunk might
|>still not do what you want.  If branch B branched first, then 2->4 may
|>back out changes made to the trunk between the base of B and the base of
|>A.  If A branched first, then 2->4 will attempt to remerge changes made
|>to the trunk between the base of A and the base of B, causing the same
|>sort of spurious conflicts you were attempting to avoid.
|>
|>The only clean way to do this in the general case is to tag branch B
|>before and after your merge from A at point 3 and merge B back into the
|>trunk as two merges:
|>
|>~    cvs up -j 1 -j pre-3
|>~    cvs up -j post-3 -j 4
|
|
|If you do this, are you missing the changes between points 2 and 3 on
|branchA that should (I think) end up merged to the trunk?


Oops, yes, you are correct.  What I said was correct if point 2 & 3 were
the same (at point 2 all of branch A was merge to both the trunk and
branch B).  A clean merge to the trunk without conflicts from a repeated
merge with distinct points 2 & 3 would require the two commands I listed
above and a third merge:

~    cvs up -j 2 -j 3

Derek

|>Please note that I am using numeric tags in the above example, per the
|>ascii art below, despite the fact that tags that start with a number are
|>invalid.
|>
|>Derek
|
|
|Thanks,
|Jamie
|
|>Get CVS support at <http://ximbiot.com>!
|>
|>
|>David Wood wrote:
|>
|>|I would say your ascii graphic is admirable!
|>|
|>|What you are saying matches what I'm seeing in tests, and I think I
get it
|>|now.
|>|
|>|I believe my problem has been a silly confusion with the way update -j -j
|>|works.
|>|
|>|I understand a merge between 1 and 4 (and for that matter, a
reverse-merge
|>|between 4 and 1) well enough.
|>|
|>|Essentially, I mistakenly envisioned a merge between 3' and 4 - rather
|>|than 2 and 4. Hence my fear about loss or mistreatment of changes before
|>|the child-to-child merge.
|>|
|>|I think what all this means is that branchB is now essentially merging
|>|against branchA (having received common chagnes by, and resolved
conflicts
|>|with) branchA... and the merge delta with the trunk must now use branchA
|>|(at point 2) as a reference point in order to correctly reflect changes
|>|against the trunk.
|>|
|>|It is potentially confusing, but you have made it seem very simple. Thank
|>|you!
|>|
|>|-David
|>|
|>|Jamie Wellnitz <address@hidden> wrote on 11/04/2003 11:50:35
|>|AM:
|>|
|>|>Sorry for the ascii graphic in advance . . .
|>|>
|>|>If you have (* indicates merge point):
|>|>
|>|>branchA and branchB originated from trunk at point 1.
|>|>branchA merged to trunk at point 2 on branchA and 2' on trunk.
|>|>branchA then merged to branchB at point 3 on branchA and 3' on branchB.
|>|>Now, we want to merge branchB (point 4) to the trunk (4').
|>|>
|>|>              branchA  2    3
|>|>            /---------\-----\-------->
|>|>         1 /           \     \           4'
|>|>trunk ------------------*---- \ ---------*---->
|>|>           \            2'     \        /
|>|>            \-------------------*------/-->
|>|>              branchB           3'     4
|>|>
|>|>I think you want the common ancestor of the current branchB tip and
|>|>trunk tip.  That would be point2 on branchA.  (This is assuming you
|>|>did a full merges, not just a few changes, from A->trunk and A->B.)
|>|>So assuming you put tags down to keep track of the merge points, you
|>|>might try (on the trunk):
|>|>
|>|>cvs update -j point2 -j point4
|>|>
|>|>It looks like my point2 is your "first child merge point" and "second
|>|>child" is the tip of branchB (where you put a tag before the merge).
|>|>
|>|>Which changes before the "first child merge point" are you wondering
|>|>about?
|>|>
|>|>Thanks,
|>|>Jamie Wellnitz
|>|>address@hidden
|>|>
|>|>On Tue, Nov 04, 2003 at 11:06:44AM -0500, David Wood wrote:
|>|>
|>|>>Let me try to put it another way.
|>|>>
|>|>>I have a parent branch, and it has two child branches. If I want one
|>|
|>|child
|>|
|>|>>to merge to the parent, and then to the other child, how does that
|>|
|>|other
|>|
|>|>>child later merge to the parent as well?
|>|>>
|>|>>Is it (on the parent): update -j first_child_merge_point -j second
|>|
|>|child
|>|
|>|>>If so, what happens to changes from before the
|>|
|>|first_child_merge_point?
|>|
|>|>>-David
|>|>>
|>
|>- --
|>~                *8^)
|>
|>Email: address@hidden
|>
|>Get CVS support at <http://ximbiot.com>!
|>- --
|>I know of no safe depository of the ultimate powers of the society but
|>the people themselves, and if we think them not enlightened enough to
|>exercise that control with a wholesome discretion, the remedy is not to
|>take it from them, but to inform their discretion.
|>
|>           - Thomas Jefferson, 1820.
|>-----BEGIN PGP SIGNATURE-----
|>Version: GnuPG v1.0.7 (GNU/Linux)
|>Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org
|>
|>iD8DBQE/p+98LD1OTBfyMaQRAkYYAJsFs2zGGAUbt4iA5k/o3GxATtu9ZgCfcngq
|>sDzUwcIwQzAV5U0g6Tjo05w=
|>=0iYB
|>-----END PGP SIGNATURE-----
|>
|>
|>
|>
|>_______________________________________________
|>Info-cvs mailing list
|>address@hidden
|>http://mail.gnu.org/mailman/listinfo/info-cvs


- --
~                *8^)

Email: address@hidden

Get CVS support at <http://ximbiot.com>!
- --
f u cn rd ths, u cn gt a gd jb n cmptr prgrmmng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org

iD8DBQE/qAs7LD1OTBfyMaQRAlIFAKDv227HNRQ2c91UAyBGpSm6FiO0nQCgnTNg
KctsOe+x4vvBjeHKbFrUF7E=
=BrPZ
-----END PGP SIGNATURE-----