Re: Results of egrep -l '^<<<<<<< |^=======$|^>>>>>>> |^\|\|\|\|\ \|\| '

[Paul Sander]

>--- Forwarded mail from address@hidden

>>>(The debate with Paul on this one started because he seemed to think you
>>>should be able to do "cvs diff | mail vendor" and get the vendor to take
>>>back all your changes or something.  I think he was just being contrary.)
>>
>>That is not at all what I conveyed.  My question was:  What if the files
>>that contain the conflict mark-ups are supplied by the vendor, to be
>>checked in on the vendor branch?  Do you now expect CVS to be able to
>>tell the difference between vendor branches versus any other branches,
>>and allow the user to commit files containing arbitrary text on vendor
>>branches while refusing commits elsewhere if files contain conflict
>>mark-ups?

Oh, one other little detail that escaped my above comment:

Suppose I receive a file from a vendor that happens to contain a merge
conflict mark-up.  I check it in successfully on a vendor branch.  I merge
it my trunk.  I make another modification to the file.

In this case, I must commit the file (CVS did not introduce the conflict
mark-up in this case, and I really don't want to change it).  I should
definitely be able to do a "cvs diff | mail" to get my change to the vendor.
And that change will not include the conflict mark-up because that part of
the file has not changed.

Also, if I am required by CVS to hide or otherwise escape the mark-up, then
the vendor will see it as a gratuitous change and refuse to accept it.  Then
we'll both have to propagate this difference, re-doing and re-undoing it
in perpetuity.  This is an unnecessary overhead, and CVS has no business
imposing it.

>OK, I didn't think I made up the content of your email in my head -- at least
>now I know my memory isn't that short :-)

>>Now, given your requirement that CVS refuse to commit certain files
>>(namely, files containing conflict mark-ups, though there's no guarantee
>>that you or someone else might amend this list of offensive material at
>>a later time), what is CVS to do?  It can't do it both ways, unless
>>Noel's recommended "cvs commit -f" option is implemented.

>I want to note that "cvs ci -f" is not even close to being an ideal solution.
>The problem is that there are several conditions where "cvs ci -f" will 
>override
>checks (eg identical files, missing edit when using the "cvs ci -c" patch).  
>You
>may actually want "cvs ci" to abort when some of these conditions exist, but 
>not
>when conflict markers exist.

>It may be better to have yet another option to override any marker checks.  Or
>what about an option in CVSROOT/config?  Again, I want to make it clear I am
>against checkin aborting due to marker detection, but, if this were introduced,
>it should still be left to the user to decide whether they want it or not.

Then perhaps your -f option should split into several:  One to omit the
conflict marker checks, another to force a checkin of subsequent identical
versions (though I don't see the value of doing so in CVS), and so on.

Yes, I think that the flag to skip the mark-up check should be configurable.
I don't care if it's per-user or per-site, and I don't care what the default
is.  But it is important that it be possible to disable conflict marker
check to the extent that CVS does not prohibit commits in their presence.
(Note that I do not require that warnings be disabled, so the checks can
continue as long as they don't abort a commit.)

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