[Top][All Lists]

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

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

From: Paul Sander
Subject: Re: How well does CVS handle other types of data?
Date: Sat, 14 Jul 2001 01:28:12 -0700

>--- Forwarded mail from address@hidden

>[ On Friday, July 13, 2001 at 20:19:13 (-0700), Paul Sander wrote: ]
>> Subject: Re: How well does CVS handle other types of data?
>> I hope your hack doesn't make it into the general distribution.  The
>> comment makes total sense.  The authors have no idea if the conflict
>> marker results from an artifact of the source code, or from the merge
>> program.
>> The way people usually "hide" stuff like this is to run an additional
>> filter, such as sed, over the source to convert into the real compilable
>> source.  This is a horrible kludge, and is way worse than getting a
>> conflict warning.

>Obviously you're not thinking straight.  All scenerios I can even
>imagine, plus all the real ones I know of (including all those mentioned
>in the code comment I quoted) allow "hiding" or "escaping" of content
>that looks like conflict markers from the CVS checks for such markers
>with no added external processing, no loss of functionality, no loss of
>accuracy, and no loss of meaning.

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.

>It seems you also conveniently ignored the need to internally document
>the presence of content that looks like conflict markers such that
>future maintainers won't mistake it for what it looks like.

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

>Indeed the act of "escaping" such content from detection by CVS *adds*
>information that's important to future maintainers of the file in
>question!  (at least for as long as that file is managed by CVS)

Any programmer experienced in that hypothetical language can differentiate
between CVS' conflict mark-ups and correct syntax.  An experienced
programmer on the project knows whether or not the construct in question
is valid.  Escapes buy nothing.

In any case, it's not CVS' place to impose any kind of standard on the content
of the files it manages.  So telling me that I must insert syntactic sugar in
my source code to please it is completely off base.  Any such feature must
have a way to permanently disable it (on a per-file basis), just as -ko
disables CVS' interpretation of keywords, so must there be a way to eliminate
the need for other automatic transformations or interpretations of a file's

>(and yes, even if there's no mechanism for escaping special content like
>this there's always the ugly filter kludge, but the need for such a hack
>will be extremely rare, if ever....  The possibility is so remote I
>didn't get so far as to think about the solution until you mentioned it!)

>You're beginning, again, to grasp at straws!

Yes, it is rare.  But the user is in for a big surprise if CVS disallows
a commit because it doesn't like the contents of a file.  The fact that
it is unlikely to happen does not give CVS license to impose a coding

>> Please, don't modify "cvs update" to skip files with these markers in them.
>> Again, they may be a valid artifact of the source.

>Paul, we know you don't use CVS regularly any more (or at least that's
>what I recall you saying recently -- which begs the question of why you
>continue to debate in this forum).  In any case it's obvious from your
>comment above that you've either never done enough merging and
>concurrent editing to encounter this ultimate mess of multiple
>conflicting conflicts; or you've conveniently forgotten about it.  You
>should try to quit pontificating and allow other regular users a chance
>to relate their real experiences here.

I do use CVS regularly, for the toy projects that it's best suited for.
I don't recommend it for commercial use for reasons I've stated for several
years.  The topic of this thread is one of those reasons.

I have used CVS for large commercial projects, for several years, as user,
admin, and maintainer.  I have had to perform difficult merges, even merges
from multiple branches, and support others doing the same.  (For some reason,
some developers like to perform all merge activity before a single commit,
rather than committing between branch merges.  I know better, but I can't
always convince others of the wisdom of making merges smaller.)

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

>> One other thing, too:  Leaving CVS as it is in this matter makes it easier
>> for other users to swap out the RCS merge tool with something better by
>> hard-coding in a new program.

>WHAT are you talking about?  Have you even looked at the code this part
>of CVS?  CVS doesn't use any "RCS merge tool" and it's impossible to
>hard-code any other program in there without making drastic changes!

I have mentioned many times that some users might find it desirable or
necessary to replace CVS' built-in merge tool with something more suitable
to their needs.  You have been reading this thread, have you not?  I have
also called many times for a mechanism to configure CVS to invoke a
site-supplied merge tool as appropriate for the data type of the source
files involved.

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.

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

reply via email to

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