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 sales@march-hare.com.
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 1.1.2.1
Done:
$Header: /opt/cvs/null/ak/t4.txt,v 1.1.2.1 2007/01/12 15:31:27 krey Exp $
one
two
> Make changes on A - Revision 1.1.2.2
Done:
$Header: /opt/cvs/null/ak/t4.txt,v 1.1.2.2 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)->1.1.2.3
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 1.1.2.3 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 1.1.2.3
Merging differences between 1.2 and 1.1.2.3 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:1.1.2.3)->1.2
Let's see: cvs diff -u -r1.1 -r1.1.2.3 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 1.1.2.3 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(1.1.2.3:1.1.2.3)->1.2 (ie. a null diff, losing the changes in
> 1.1.2.1 and 1.1.2.2).
This is not what the patch does, obviously. It chooses the diff from
1.2 to 1.1.2.3 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---------+
| |
| 1.1.2.1
| |
1.2 1.1.2.2
| |
+-----> 1.1.2.3
| |
1.3 <-------+
| |
> In the bidirectional case the revision 1.1.2.1 and 1.1.2.2 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