Re: Coflict marker detection proposal

[Paul Sander]

>--- Forwarded mail from address@hidden (Greg 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.

"Probably" does not cut it.  The user has the final responsibility to
decide what is acceptable to be committed, not CVS.  BTW, does anyone
commit the raw results of a merge, before resolving conflicts and
re-committing?

>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.

I've had to resolve double-merges, and it's not pretty.  But on the
other hand, the users should be educated enough to know that they
really should not attempt multiple merges between commits.  This is
as much of a training issue as anything else.

>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)

Okay, we can remove the warning, then!  ;-)

Seriously, it's arrogant of the tool designer to think that they can
anticipate every possible use of the tool.  It is not reasonable to expect
that conflict markers can't be introduced into files by some mechanism
other than CVS.

>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!).

But apparently it put up sufficient needless overhead to compel one of
the maintainers to make a change.

>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 don't believe that using the RCS "state" clause in a delta phrase is
the right way to go.  Once a file has been been "Dead" and brought back,
its "mergable-ness" is lost.  As additional RCS states are used (and
there have been proposals to use them) then using it for this purpose
becomes impossible.

It's better to put it in a newphrase at the admin level.  That way, the
condition is set once and requires no maintenance.  (Well, unless the
type of the file's content is changed, but that introduces another flaw
in CVS' design.)

>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?

You have to understand that allowing CVS restrict, however rarely, the
contents of a file given to it to be stored in the repository, is a
dangerous precedent.  By limiting the contents of some files, someone
later will decide that they can be limited a little more.  And a little
more, and a little more.  After a while, the limitations aren't so rare
anymore.

So the best solution is not even to begin down that slippery slope, and
require CVS to commit anything and everything it's given.

>--- End of forwarded message from address@hidden