[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Disallowing commits in presence of conflict markers

From: Greg A. Woods
Subject: Re: Disallowing commits in presence of conflict markers
Date: Sat, 14 Jul 2001 19:13:31 -0400 (EDT)

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

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.

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

You're grasping at straws, again.

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

If you really insist you could bend the '-kb' flag to also disable this
safety check too.....  I won't bother in the version of CVS I use, of

No doubt before such a change should be publicly published it should
also be enhanced to provide a warning if an existing file is checked out
that contains what appear to be unresolved conflicts.  I'll probably do
this myself anyway because I may have actual unresolved conflicts in
some documentation files that I've not proofread carefully.....

                                                        Greg A. Woods

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]