Disallowing commits in presence of conflict markers (was Re: How well does CVS handle other types of data?)

[Paul Sander]

>--- Forwarded mail from address@hidden

>[ On Saturday, July 14, 2001 at 01:28:12 (-0700), Paul Sander wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>>
>> And just how is this done?  Do you use artifacts of the programming language
>> to somehow format the marker into something that is not detectable by CVS?
>> What if the language provides no way to do this?  Seems to me that in that
>> case you're screwed either way.  You can't put them in because your tool
>> breaks.  You can't leave them out because CVS disallows commits if you do.

>Why don't you look at doc/cvs.texinfo and src/sanity.sh and figure this
>out for yourself?

>> What does that have to do with anything?  The tools don't read the comments.

>Who said anything about comments?  I certainly didn't.  I said
>"document".  There's a difference.

I've looked at those files, and I see the way that the author has cleverly
inserted syntax that does not change the operational characteristics of the
code while making it appear different from the conflict markers that CVS
seeks.

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.

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.

>> In any case, it's not CVS' place to impose any kind of standard on the 
>> content
>> of the files it manages.

>Well, obviously you live in a dream world where everything's got to be
>perfect or else it's useless.

>CVS imposes many subtle issues on the content of the files it manages,
>and I'm not talking just about them being "RCS mergable".

CVS works best with ASCII text files that merge will with the RCS merge
tool.  It works less well with ASCII text files that don't.  It works poorly
with files that are not ASCII text.  It performs keyword expansion, which can
be disabled.  It performs newline conversions, which can be disabled.  It has
the conflict marker heuristic, which can be ignored when appropriate.

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.

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.

>> It is precisely because I HAVE performed and supported difficult merges,
>> including with binary sources (which you admitedly avoid), that I crave much
>> better support for it.  CVS has lots of room to improve, and this is one such
>> area.

>Well, I've just done something about it in the version of CVS I use.  It
>works GREAT!

Good for you.  Keep it.  I just hope your change doesn't go into the general
distribution, because it will cause CVS to fail to meet one of its most
basic requirements in the general case.

>> I looked at the CVS sources just now.  Hasn't changed much lately.  There
>> are two functions that perform the guts of the merge.  The first is the
>> RCS_merge function, which performs the ASCII-based merge we all know and
>> love.  One level up is the merge_file function, which puts a better face
>> on it, and implements the -kb support.  The interfaces of both are quite
>> clean, and the call graph is such that there is little chance that changing
>> either of them will break something else.  It appear offhand to be trivial
>> to insert new merge capabilities; well, nothing is trivial in programming,
>> but this certainly does not involve "drastic changes" that Greg promises.

>How little you understand what's really going on in there it seems......

I've been using CVS for over ten years now, so I'm very experienced at it.
I've dug into its innards many times, and even made significant changes to it
(some of which are in the general distribution, others not).  I've just
reviewed the latest code to make my point, just in case there's something
new.  I think I understand very will what's going on in there.  Sounds to me
like you're spreading FUD.  Don't do that.

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