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

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Friday, July 13, 2001 at 16:40:47 (-0400), Noel L Yap wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>>
>> I think this is only partially true.  Since CVS doesn't currently absolutely
>> know whether there are any remaining conflicts, why would it be a requirement
>> when doing manual merges?  For example AFAIK, if I get a conflict upon 
>> update,
>> then touch the file, CVS will gladly check it in for me.  Is this correct?

>If that's true then that's a bug.

>CVS is supposed to look for conflict markers in files and abort a commit
>if it finds any.

>Well, actually it seems you'll only get a warning currently....  Grrr...
>I'll be fixing that _right_now_ in my version!

>The code in commit.c says:

>                if (file_has_markers (finfo))
>                {
>                    /* Make this a warning, not an error, because we have
>                       no way of knowing whether the "conflict indicators"
>                       are really from a conflict or whether they are part
>                       of the document itself (cvs.texinfo and sanity.sh in
>                       CVS itself, for example, tend to want to have strings
>                       like ">>>>>>>" at the start of a line).  Making people
>                       kludge this the way they need to kludge keyword
>                       expansion seems undesirable.  And it is worse than
>                       keyword expansion, because there is no -ko
>                       analogue.  */
>                    error (0, 0,
>                           "\
>warning: file `%s' seems to still contain conflict indicators",
>                           finfo->fullname);
>                }

>It should be an error though, despite the comment.  The logic in there
>is flawed.  There are almost always a way to "hide" conflict markers
>from the file_has_markers() check (which is what the comment means by
>"kludge this").  In fact the correct work-around when conflict markers
>are desired in a file *is* to kludge them with whatever hiding technique
>is appropriat for the code in question.  That way they're properly
>documented as being part of the code, not an accident!

I hope your hack doesn't make it into the general distribution.  The
comment makes total sense.  The authors have no idea if the conflict
marker results from an artifact of the source code, or from the merge
program.

The way people usually "hide" stuff like this is to run an additional
filter, such as sed, over the source to convert into the real compilable
source.  This is a horrible kludge, and is way worse than getting a
conflict warning.

>Maybe, just maybe, it might be good to avoid this check if '-kb' is set,
>but as the comment hints it would be better to invent a proper flag
>which means only "don't check for conflicts".

>CVS should also check for conflict markers when doing a "cvs update" and
>abort any further updating too, but I don't think this latter issue has
>been widely discussed.  There's no worse task in merging than trying to
>sort out a series of nested conflict markers!  I may even add this
>feature in my version if it seems easy while I'm in there fixing the
>previous bug too...

Please, don't modify "cvs update" to skip files with these markers in them.
Again, they may be a valid artifact of the source.

>I'm glad this came to light now -- not after I've started my next merge
>of NetBSD!  ;-)

One other thing, too:  Leaving CVS as it is in this matter makes it easier
for other users to swap out the RCS merge tool with something better by
hard-coding in a new program.

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