Re: Conflict marker detection debate (Was: How well does CVS handle other types of data?)

[Noel L Yap]

>[ On Monday, July 16, 2001 at 10:03:48 (-0400), Noel L Yap wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>>
>> I think a proper patch to this would be to use hashes as well (or in lieu of)
>> timestamps.  The hashes possibly can be cached to speed up comparisons.
>>
>> CVS should not be looking for conflict markers:
>> 1.  Doing so will tie in the diff3 even more than it is now.
>
>There's no other way than to tie in the merge ``algorithm''.  Think
>about it!  How do you ever tell when conflicts are finally resolved
>other than by explicitly looking for whatever indicators the merge
>algorithm left behind when it detected a conflict.  You cannot rely on
>timestamps, and you cannot rely on unverified input from the user.

It's up to the user and processes to make such verifications.

>> 2.  It will prevent checkin of files that legitimately contains the markers,
not
>> catch real conflicts in such files, or introduce new markers to mark the
>> instances of conflict markers that CVS should ignore.
>
>That's the most bogus and illegitimate argument ever!

But in another thread, you actually said "Absolutely" to the first part.

>It is *ALWAYS* trivial to hide markers in legitimate content, even with
>a hack in the external build system as Paul Sander conveniently suggested.

So now you want to change the build system as well?

>Why doesn't everyone on this list try the following on their systems:
>
>  find / -type f -print | xargs egrep -l '^<<<<<<< |^=======$|^>>>>>>>
|^\|\|\|\|\|\|\| '
>
>If you find results anywhere but in the likes of the diff3 and cvs
>binaries themselves, or of course in any working files with unresolved
>merge conflicts, please report back here.

What about those not on this list?

Anyway, you haven't come up with an argument other than, "Bull.  That's just
plain ignorant." to the statement, "Any VC tool should allow any file to be
committed as is."

>> If developers want to prevent files with conflict markers from being checked
in,
>> they can use commitinfo to do so.
>
>I think that's a stupid (and yes I mean that literally) suggestion.
>
>CVS itself introduces the ugly mess of conflict markers -- it must
>ensure the user has cleaned up that mess before it permits a commit or a
>subsequent merge that'll only mess things further.

Why must it?  What's wrong with a warning?

Suppose I generated the file using diff3 myself.  CVS wasn't involved in
creating the markers, it shouldn't do any enforcement.

OK, I've created a file whose contents are:
<<<<<<<
=======
>>>>>>>

I'm putting it in my repository.  Look, it comes up in a grep!  Now can we drop
this nonsense?

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.