(LONG-ish) Bringing cvsnt mergepoint processing into CVS: request for feedback

[Phil Richards]

As a follow on from Derek Price's request for help way back...
(This would have come through a month or so ago, so ignore the
references to the New Year - darned bug-cvs mailing list :-)


I will have some time in the New Year to try to bring the one feature of
CVSNT that I really like into CVS: what CVSNT calls "mergepoint
processing" (Tony Hoyle laid the foundations for it - I did some fairly
simple work to make it more flexible).

Before I start doing anything significant, it would probably be a good
idea to get some feedback on two things:
 1. People's view of the current approach;
 2. What limitations people are prepared to live with.

To set the scene (without going into too much detail):

The CVSNT mergepoint processing kicks in when:
    cvs update -jBRANCH file
is invoked.  It does not (and is not meant to) handle "-jREV1 -jREV2"
cases.  We can assume (for now, anyway) that BRANCH is a branch name
different to the current branch.  (I will use the term "branch" to
include the mainline as well.)

Merging is done exactly as in core CVS; the main difference is that
information about precisely which revision on branch BRANCH was merged
in is recorded in the client CVS directory (call it BRANCH.f1).

When "cvs commit" is performed on the file, this information is sent
back to the server, and as a per-revision property in the ,v file.

Next time "cvs update -jBRANCH file" is invoked, the merge is invoked
using BRANCH.f1 as the starting point, and the end of BRANCH.
BRANCH.f1 is found by trawling back through the revision history
for the last mergepoint recorded for "BRANCH".

This is functionally equivalent to the usual "tag-the-branch"
and "use-j-j-merge" - its advantage is that it works transparently.

Inter-merging between two branches works (roughly) the same way -
in practice it is possible to merge main-to-branch and branch-to-main
repreatedly and it all does what would be expected (it works by
identifying the most recent common mergepoint, and using that as the
starting point for the merge).


The main limitations/problems/issues as I see them[*]:
 * During the "cvs update -j"->"cvs commit" stage, the merge point
   is recorded in CVS/Entries.Extra (a new file).
 * Merging from main-to-branch1, main-to-branch2, and then
   branch1-to-branch2 will not do the "right" thing.  
 * Performing multiple cvs update -j's, from different branches,
   without a intermediary commit will confuse things.

The first point is not a problem, as such, but it would be nice to
eliminate the need for another pair of files (Entries.Extra and the .Log
version) that need to be kept in step with Entries.  A possible approach
might be to reuse/extend the "+CONFLICT" part of the timestamp field,
but I think the knock-on effects are probably going to cause grief for 
other clients.  This is one where I would really appreciate some

The second point is a usability issue, but resolving it is (at first and
second look) distinctly non-trivial.  Would it be acceptable for the
first cut of any core CVS approach to keep this limitation?

The third point is not really that important - the workaround is
trivial and good practice anyway: just commit each merge after they
are done.


The bigger question: does anybody actually want "mergepoint" processing
adding into core CVS apart from me?


Any thoughts/suggestions?

phil

[*]There are more things that could be raised, but I don't want this
initial posting to get too large.
-- 
SPAM CATCHER ALERT: change name before "@" to "phil" for email