[cvsnt] Mergepoint issues on 2.5.0.3 b2382

[Richard Wirth]

Hello Arthur, hello Andreas,

May be Tony has tested a different solution than provided in the patch
by Andreras?

The patch works as follows:

it looks for a mergearrow between both branches involved. Regardles of
the direction of that mergearrow it take the base of youngest one.
Than the diff between that version and the tip of the source branch is
merged into the target branch (3-way-diff).

As you can see from Andreas' sample:

For 'forward' merge the diff is build on two HEAD-revisions (1.1 and
1.2).

For the 'backward' merge the diff is build on HEAD and branch revision
(1.2 and 1.1.2.2).

The next 'forward' merge would use 1.1.2.3 as the base for diff, and
so on...

That's the key!



So for the trivial case where only merges between two branches take
place, it will fullfill the needs.

For complex scenarios the whole merge tree has to be scanned to find
the base revisions for merge...
For complex scenarios it is not possible to always find two revisions
for merging. There the merging has to be done in multiple steps, which
is not to be done automaticaly an more.

>> >From Tony Hoyle's e-mail Dateed: Mon, 05 Jun 2006 14:45:39 +0100
>> >
>> > It's very easy.
>> >

AK> Create file 1.1

>> > Branch

AK> Tag on 1.1.0.2

>> > Make changes in B

AK> Yielding 1.1.2.1

AK> To make it not-quite-trivial, I also changed the head to 1.2.
AK> If I don't the Merge A->B does not yield anything to commit
AK> (since there wasn't any change on the head (resp. A) since
AK> the branch).

>> > Merge A->B

AK> RCS file: /opt/cvs/null/ak/test.txt,v
AK> retrieving revision 1.1
AK> retrieving revision 1.2
AK> Merging differences between 1.1 and 1.2 into test.txt

AK> Merge base versions are as expected, and the
AK> file contents as well -> 1.1.2.2

>> > Merge B->A

AK> RCS file: /opt/cvs/null/ak/test.txt,v
AK> retrieving revision 1.2
AK> retrieving revision 1.1.2.2
AK> Merging differences between 1.2 and 1.1.2.2 into test.txt

AK> Again, the proper merge bases have been selected, and
AK> the resulting file is as expected (containing modifications
AK> from head and branch) -> 1.3.

AK> Actually 1.3 and 1.1.2.2 are identical, which you expect
AK> after merging both ways with no intervening changes.

>> > If you use the merge point the changes in the second step are lost.

AK> Nope. Worked like a charm.

....

-- 
Best regards,
 Richard                            mailto:richard at wirthware.de