[cvsnt] Re: Mergepoint question

Phil Richards news at derived-software.ltd.uk
Fri Jul 25 23:15:17 BST 2003


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.


Glen Starrett wrote:
> FWICT, CVSNT handles that rather handsomely.  I did some experimentation
[...]
> You'll notice the "mergepoint" fields in all records where I did a merge,
> and the mergepoint record always contains the "from" version that was merged
> in (the record already has the "old" and "new" of the file being merged).

The mergepoint records are, indeed, correct.  Unfortunately, what is wrong
is the delta that is being applied during the merge operations.

Here is what happens in detail:

(Caveat: it's late at night, mergepoint processing is fiddly, and
I may well have cocked this up.)

Create a file (revision 1.1)
Branch it (branch 1.1.2)
Create revision on the mainline (1.2)
Create a revision on the branch (1.1.2.1)
Merge mainline to branch and commit it (1.1.2.2, mergepoint 1.2)
Add a revision on the branch (1.1.2.3)
Add a revision to the mainline (1.3)
On the mainline, perform a merge from branch.

This is what I get with the last build of CVSNT under Linux (I can't
build the current cvs tree under Linux, so it's quite an old build -
maybe the behaviour is different in the latest Windows build - I can't
test it 'cos I'm not at work):

cvs update -jbranch c
RCS file: /home/pgr/cvsnt-test/merges/c,v
retrieving revision 1.1
retrieving revision 1.1.2.3
Merging differences between 1.1 and 1.1.2.3 into c
rcsmerge: warning: conflicts during merge
C c

Ignore the merge conflict stuff for now: what is important is that the
delta from 1.1 (the branch point) to 1.1.2.3 is being applied to 1.3.

This is wrong - 1.1.2.3 includes the delta from 1.1->1.2,
and this is now being reapplied to the mainline, which, unsurprisingly
already includes this particular delta.  The best you can hope is that
CVS will notice this and not do it.  In the worst case, it will reapply
the change.

The delta should probably be 1.2->1.1.2.3.  This is made up of two
bits: 1.2->1.1.2.2 is the change to the mainline required to bring
it to include the branch contents as of version 1.1.2.1 *and* include
the mainline up-to version 1.2.  1.1.2.2->1.1.2.3 is the change needed
to include all development since the last mainline-to-branch merge.

[Btw, it can't be 1.1.2.2->1.1.2.3 since this misses the change 
from 1.1->1.1.2.1.]

If you look at the conflicts, you find that the stuff added at revision
1.2 appears in both branches of the merge conflict (i.e., it has been
reapplied).

Now, do the merge from from 1.2->1.1.2.3 on to 1.3 by hand (-j1.2 -jbranch)
You still get a conflict, but the conflict is now the "correct" one.

CVSNT should, in principle, be able to work out that "1.2" is the revision
to use - it has it recorded.  (Btw, it isn't always this simple, but
the information is, in all the cases I've looked at, available.)

Time for bed said zebedee...

phil
--
change "spam"/"news" to "phil" to email me


More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook