[cvsnt] Mergepoint issues on b2382

Tony Eva teva at Airspan.com
Mon Jan 15 10:12:15 GMT 2007

I've been staying out of this thread until now, even though I started
the original discussion back in June last year.  That's mainly because
Andreas and Andy are articulating my viewpoint better than I could, and
I support everything they have said so far in this thread 100%.

That said, it really looks like both sides are firmly entrenched in
their views and are not open to being persuaded.

On one hand, we (Andy, Andreas, me) fully understand how bidirectional
merges work, when to use them and when not to, and in fact we all *have*
used them for years without any data loss and want to continue to do so.
It is especially frustrating for us that CVS *used* to support this
functionality, and it was one of the biggest factors that caused us
(well, my group anyway) to make the migration from plain CVS to CVSNT;
so to have it removed again was a special irritation.

On the other hand, I can see that Tony Hoyle and Arthur believe strongly
that this functionality will cause problems.  We happen to disagree -
equally strongly! - but let that pass; I understand that March Hare has
to support their paying customers, they have to pick up the pieces, and
it's hard to explain to a paying customer why your product does
something when you don't actually believe yourself that it should be
doing it.

However, we are now facing the situation where at least three groups of
developers are heading off independently with home-brew patched versions
of CVSNT in order to get this previous capability restored.  This cannot
be a good thing.

So, I'd like to make the proposal (suggested earlier) that the
bidirectional mergepoint support is reinstated in the official CVSNT
2.5.0x stream, but under the -J option instead of -j (the latter would
retain its current one-way mergepoint function).  The help text for the
update command can have a note to say that the -J option should be used
with caution, and the manual can have text to describe its operation and
if necessary have a prominent warning note that the option should not be
used unless its function is fully understood.

However, I would very strongly resist the suggestion that a warning
message should be displayed whenever the -J option is used, for the
simple reason that it will be seen by non-CVS literate developers who
are following a standard laid-down process: they could be unecessarily
confused and spooked into trying to fix non-existent problems in their

Arthur: if a patch of this nature is developed, and submitted in the
cvsnt-dev list, are you (as CVSNT maintainer) prepared to accept it
(subject to the usual inspections and revisions)?

Tony Eva

More information about the cvsnt mailing list