Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to firstname.lastname@example.org.
On Fri, 12 Jan 2007 14:23:12 +0000, Tony Hoyle wrote: ... > The problem is if you merge A->B you cannot assume that A==B. Nobody ever did that. > Merge A->B means that B contains A (possibly changed a bit due to > conflict resolitution, so B might not contain A at all in the most > pathalogical case). It does not mean that A contains B. Right. That's why merge arrows have a direction. > Let's go through this again. For the final time. Ok. > Create file - Revision 1.1 Done. Plus branch-tagging. $Header: /opt/cvs/null/ak/t4.txt,v 1.1 2007/01/12 15:30:16 krey Exp $ one > Commit a revision to A - Revision 22.214.171.124 Done: $Header: /opt/cvs/null/ak/t4.txt,v 126.96.36.199 2007/01/12 15:31:27 krey Exp $ one two > Make changes on A - Revision 188.8.131.52 Done: $Header: /opt/cvs/null/ak/t4.txt,v 184.108.40.206 2007/01/12 15:32:06 krey Exp $ one two four > Make changes on HEAD - Revision 1.2 Done: $Header: /opt/cvs/null/ak/t4.txt,v 1.2 2007/01/12 15:32:43 krey Exp $ one three > Merge HEAD->A - diff(1.1:1.2)->220.127.116.11 sd [~/null/ak-br] 531: cvs update -jHEAD t4.txt RCS file: /opt/cvs/null/ak/t4.txt,v retrieving revision 1.1 retrieving revision 1.2 Merging differences between 1.1 and 1.2 into t4.txt rcsmerge: warning: conflicts during merge C t4.txt The expected conflict (whose resolution is obvious): $Header$ one <<<<<<< t4.txt two four ======= three >>>>>>> 1.2 Cleanup and commit: $Header: /opt/cvs/null/ak/t4.txt,v 18.104.22.168 2007/01/12 15:34:39 krey Exp $ one two three four > Merge A->HEAD Let's first see what happens here (patched cvsnt): sd [~/null/ak] 529: cvs update -jtmp-ak-test-br t4.txt RCS file: /opt/cvs/null/ak/t4.txt,v retrieving revision 1.2 retrieving revision 22.214.171.124 Merging differences between 1.2 and 126.96.36.199 into t4.txt Conflict-free merge, resulting in $Header: /opt/cvs/null/ak/t4.txt,v 1.3 2007/01/12 15:37:24 krey Exp $ one two three four > With one directional mergepoints: > diff(1.1:188.8.131.52)->1.2 Let's see: cvs diff -u -r1.1 -r184.108.40.206 t4.txt yields -$Header: /opt/cvs/null/ak/t4.txt,v 1.1 2007/01/12 15:30:16 krey Exp $ +$Header: /opt/cvs/null/ak/t4.txt,v 220.127.116.11 2007/01/12 15:34:39 krey Exp $ one +two +three +four You would merge the lines 'one', 'two', and 'three' into 1.2 which already contains the line 'three'. *This* is just wrong. But then, you don't claim to get that right. Basically you do the merge into the head as if the merge into the branch never happened. That way you get the modification in 1.2 into both sides of the merge. > With bidirectional mergepoints: > diff(18.104.22.168:22.214.171.124)->1.2 (ie. a null diff, losing the changes in > 126.96.36.199 and 188.8.131.52). This is not what the patch does, obviously. It chooses the diff from 1.2 to 184.108.40.206 to be merged into the head. You need to used the base of the last merge arrow as the base version for the merge, not the tip. 1.1---------+ | | | 220.127.116.11 | | 1.2 18.104.22.168 | | +-----> 22.214.171.124 | | 1.3 <-------+ | | > In the bidirectional case the revision 126.96.36.199 and 188.8.131.52 changes are > lost - and that's quite a trivial example. Except for it being wrong. > Expand it to multiple branches and revisions and it gets hard to track. In the moment you start to merge between branches that aren't parent and child, then yes. Before that it's all in the patch. Andreas -- np: 4'33