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

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Monday, July 16, 2001 at 15:04:59 (-0700), Paul Sander wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>>
>> 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.

>Sure.  OK.  That's all irrelevant though until you or someone gives us
>some working code to play with....

>> The requirement is that CVS commit any file that's given to it.

>No, that's not any requirement whatsoever.  CVS deals only with source
>files.  See my previous posting for yet another definition of source
>files.

The beauty of definitions is that they can be anything you want.

I think most of us will agree with me that CVS must be able commit any
file given to it, and reproduce it exactly.  Arguing that it should commit
only the files it deems suitable is way off the mark.

>> 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 '^>>>>>>> '

>Why don't you read the code Paul?  CVS does not use grep or egrep.

I did.  Now tell me why there's a practical difference between what the code
does and what my grep does.

>Note also that three different strings are matched by the default CVS,
>and four by my version.

I reviewed the file_has_markers function in some detail.  It matches
exactly the same set of strings as the pattern I gave above.

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