Re: How well does CVS handle other types of data?

[Paul Sander]

>--- Forwarded mail from address@hidden

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

If the existing diff3-based algorithm is replaced by another one, as I have
proposed, then a different method is needed to check for conflicts that does
not look for diff3's artifacts.  IF that merge algorithm produces some
artifact that persists after the merge and disappears after an edit (like
diff3's mark-ups do) then CVS's current conflict detection method should be
replaced with a different one that matches merge algorithm and data type.

We already know that the merge_file and RCS_merge functions are the right
place to inject new merge methods.  To complete the job we just need to
inject into the file_has_markers function a matching conflict detector.

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

The requirement is that CVS commit any file that's given to it.  That means
that it cannot refuse to commit a file that legitimately contains the diff3
mark-ups.

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

That is just a clumsy workaround, to side-step a faulty tool (in this case,
CVS).

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

If you do this, then at least use the same conflict detector that CVS does.
CVS uses the following, rather than the complicated egrep expression that
Greg gives:

        grep '^>>>>>>> '

>Beware that's a pretty messy patter for most egrep implementations.
>Fgrep really needs an option to anchor at the beginning of a line.
>Maybe I'll add such an option to my version....

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

Fine.  In the event that a different merge algorithm introduces a different
artifact, then add a matching conflict detector.  In some cases, including
the one that I propose for trivial selections, the matching conflict detector
will be /bin/false.  For diff3-based merges, the conflict detector remains
the grep search.  For other merges algorithms, use something else that's
appropriate.

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