Re: Coflict marker detection proposal

[Noel L Yap]

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

I think it may be possible for CVS to keep track of which markers it puts in.
For example, it can keep the line numbers of these markers somewhere in the CVS
subdirectory.

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

Users will quickly learn not to do this so this workaround isn't necessary.  The
real fix would be to have CVS keep track of merges (but you've been opposed to
this all along since your processes supposedly took care of this already.  I
guess they don't since you still deem there to be a problem).

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

This is exactly what I want, or rather, I don't want CVS to decide not to
checkin code that I deem correct (without there being a simple override like
"cvs ci -f")..

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

And such code may not be able to be checked in each time the conflict marker
check changes.

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

You're dodging the entire issue that CVS should not ever prevent (although I can
see where it would want to avoid) checkins of files that are deemed to be
correct.

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

If this issue is so non-important that everyone is wasting time discussing it,
why do you keep pushing your proposal on everyone?  Why not just drop the topic
and keep the distribution as is?

Noel



This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.