[cvsnt] Mergepoint issues on 2.5.0.3 b2382

[Andreas Krey]

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