Re: Disallowing commits in presence of conflict markers

[Paul Sander]

>--- Forwarded mail from Greg Woods:

>[ On Saturday, July 14, 2001 at 13:25:37 (-0700), Paul Sander wrote: ]
>> Subject: Disallowing commits in presence of conflict markers
>>
>> But my question remains:  "What if the language provides no way to
>> do this?"  Given this context, you have a file that simply cannot be
>> version-controlled by CVS because CVS does not like its contents.
>> This is not acceptable.

>You yourself provided an excellent solution.  I doubt it would ever be
>necessary though....

>> It's a requirement of any version control system to accept and faithfully
>> reproduce (identically) any version of any file placed under its control.
>> It cannot choose what it likes to accept.

>Hmmmm... I wonder why most of them offer keyword expansion then....

When offered, keyword expansion is an option, or at least it can be
disabled.

>Yes that's rhetorical, but your whole argument to this point is so inane
>I can't even bother to think of anything better.

>CVS already drastically modifies any file it merges and encounters
>conflict during the process.  I only seems fair that it ensure someone
>cleans up after it before the merge is considered complete.

My claim is that in many circumstances, namely with binary files, CVS should
not mark up a file in any way.  I'll amend that here and say that, if
conflicts are detected, then whatever conflict mark-ups are inserted must
be appropriate for the data type.  Sometimes, that means that no mark-ups
are permitted, and conflicts must be tracked in some other way.

>> Given these limitations, CVS will still allow me to commit any file and
>> faithfully reproduce it identically.  That is my most basic requirement,
>> and CVS does it reasonably well.

>CVS doesn't make any promises about non-text files.  I don't see any
>difference here with its refusal to allow a commit of what to it can
>only be unresolved merge conflicts.  CVS will still faithrully reproduce
>any file it allows to be committed.

There's the rub:  "CVS will still faithfully reproduce any file it allows
to be committed."  It's not the place of CVS to tell its users what files
are acceptable.  It must accept whatever they give them.

>> Changing the conflict marker heuristic into an operational rule (i.e.
>> failing to commit in the presence of one) violates this most basic
>> requirement; CVS can now commit some files, but not any file.

>Oh well.  I guess your magical world of perfection will never allow
>something so primitive and basic as CVS to exist within it.

>It would be you, the user, who would have to modify your precious file,
>not CVS.  CVS would still reproduce it identically (it just wouldn't let
>you initially commit anything that would appear to contain unresolved
>conflicts in the first case).

Why add the unnecessary overhead of somehow transmogrifying my source
files just to make it acceptable to CVS?  That will be an ongoing
frustration for the users, because they now are required to perpetuate
the practice.

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