-----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 <[EMAIL PROTECTED]> 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 |>|>[EMAIL PROTECTED] |>|> |>|>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: [EMAIL PROTECTED] |> |>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 |>[EMAIL PROTECTED] |>http://mail.gnu.org/mailman/listinfo/info-cvs
- -- ~ *8^)
Email: [EMAIL PROTECTED]
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-----
_______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs