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

[Greg A. Woods]

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

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

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

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>