Re: Coflict marker detection proposal

[Greg A. Woods]

[ On Tuesday, July 17, 2001 at 20:49:49 (-0400), Noel L Yap wrote: ]
> Subject: Re: Coflict marker detection proposal
>
> Then please restate them in the context of this question.

OK, just this once, just for you.

1. The presence of merge conflict markers in a source file managed by a
   concurent versioning system is generally an indication that there
   were unresolved conflicts in a recent merge.  Since in the case were
   there was a merge and CVS probably introduced those markers itself it
   thus has the responsibility to ensure they're removed before it
   allows the user to continue and commit the file (clearly a file with
   unresolved conflicts introduced by the change control system cannot
   ever be "correct").  Obviously CVS has no way to distinguish
   automatically introduced markers from any manually introduced
   "real"-looking markers, so the best it can do is require that no such
   real-looking markers are ever part of the content of any (mergable)
   source file that it manages in the first place.

2. Even if you are ignorant enough of the issues and their workarounds
   to insist on putting "real"-looking merge conflict markers in your
   source files you still don't want CVS to ever automatically attempt
   do another merge on top of any unresolved conflicts (i.e. you must
   still have "cvs update" not update any file that appears to still
   contain unresolved conflicts).  Sorting out the mess after that kind
   of event is a nasty job you wouldn't even wish upon your enemies!  It
   is simply not possible to allow merge markers, but not allow double
   merges, in mergable files.

3. Even if you are not totally ignorant of these issues and their
   trivial workarounds, but you're an arrogant snob and you're sure you
   know better than any software tool designer and so you still insist
   on putting such markers into your files in some way that they'll be
   indistinguishable from "real" markers, and since CVS will still
   always warn about such markers, it's 99.999% inevitable that some
   future maintainer will suspect they are real markers and remove them
   none the less, thus actually damaging your precious file because of
   your arrogance!  ;-)  (well perhaps I exaggerate a bit, but hopefully
   you've gotten the point straight and clear as a result)

In conclusion, the best way all around to put examples of merge conflict
markers (or similar looking things) into a source file is to ensure that
they do not actually look like "real" markers to any automatic algorithm
that searches for unresolved conflicts.  This is of course trivial in
any source file suitable for a concurrent versioning system such as CVS.
The evidence is clear in the source for CVS itself where obviously such
markers are necessary both in the code and the documentation, not to
mention the test programs and examples, yet none of these situations
causes any warning from CVS' existing checks (and indeed not
surprisingly prior to Kingdon's unilateral change didn't prevent CVS
from handling its very own code or documentation either!).

Now if we're to discuss the concept of non-mergable source files in CVS
then I've already conceded that CVS need not check for diff3-style merge
conflict markers if it has not employed diff3 on the file (eg. if a
manual merge is forced on a non-mergable source file).  I guess that's
not really a concession though since I've never once contended that CVS
should prevent non-mergable files from containing strings that could be
mistaken as conflict markers.  It's also a pretty obvious extension of
the merge algorithm too....

I've even offered a suggestion to use a new RCS "state" to indicate
non-mergable content (where a new state has the advantage of being
settable on a per-revision basis so as to allow a given filename to
undergo a transformation from containing mergable content to
non-mergable content, and vice versa).  (Obviously though any change to
CVS to better handle non-mergable content implies a change to better
track unresolved conflicts to unmergable files too, so there's more to
this issue than just adding a new flag/state/whatever to indicate a
file's (current) content is not automaticaly mergable with any
acceptable degree of success.)

I'll also note that so far nobody has come up with even a single
verifiable example of a source file (no matter what your definition of
"source file" is!) where conflict markers can't trivially be "hidden"
from the automatic detection algorithm used by CVS.  Not even when the
search for such files includes the fourth optional conflict marker only
inserted when '-e' and '-E' are not used with diff3 (eg. with 'diff3
-A').

I think you detractors have blown this issue way beyond all reasonable
porportions -- you're all grasping at non-existant straws!  Haven't you
got anything better to debate?

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>