RE: cvs update; merge

[Thornley, David]

> -----Original Message-----
> From: Frederic Brehm [mailto:address@hidden
> 
> >[ On Wednesday, August 29, 2001 at 13:42:31 (-0400), Jimm 
> Grimm wrote: ]
> >>  Subject: RE: cvs update; merge
> >>
> >>    Is there any way to get CVS to ignore CRLF conversions, 
> yet still do
> >  > merges?  I hope I am not touching a sore spot...
> 
> At 16:04 -0400 8/29/01, Greg A. Woods wrote:
> >The whole idea of putting non-mergable (binary) files in CVS 
> touches on
> >a very sore spot.
> 
> But, that's *not* what Jimm asked!
> 
It ties in.  Jimm asked for merging binary files.

> Jimm analyzed the problem this way...
> >There are four possible ways to treat files:
> >
> >11  do eol conversion   do merge
> >10  do eol conversion   no merge
> >01  no eol conversion   do merge
> >00  no eol conversion   no merge
> 
> It seems to me that cases 11 and 01 should perfectly OK with CVS, 
> since they are, by definition, mergable. CVS does not handle the 01 
> case right now.
> 
No, case 01 is not perfectly OK, for very good reasons.

CVS merges using a line-based merge.  This has been found, over years
of experience, to work very well on such things as program source files.
It isn't the fact that there is such a thing as diff3 that makes CVS
work, but the fact that using it gives meaningful, and usually correct,
results.  While it is possible to have a diff/merge (aka diff3) for
other formats, it at best isn't obvious that the result would be worth
having.

Lines exist only in text files.  If what you're working with is not text,
then what delimits lines, and how do you expect to use diff3?  When you
are using text files in a C program, you use the usual methods to process
them that go through the standard I/O library.  These control eols, and
various other things (some text files on some platforms have explicit EOF
markers, for example).

CVS doesn't use real eol conversion, but rather uses normal text files
(whatever is normal for the platform compiled on) together with a
client-server
protocol that is platform-independent.  This works very well, for the most
part.

What you are asking for is either a revised definition of text files, or
making binary files mergeable.  Either of these are going to be major
changes,
and are apparently not priorities for anybody who's actually maintaining CVS
right now.

Oh, and where does keyword expansion come in?  In these foreign text
formats,
whatever they are, should keywords be expanded or not?

> Cases 10 and 00 cause the sore spots. Ignore those. Jimm did not ask 
> about them [at least in that last message].
> 
Actually, CVS handles case 00 well enough to allow CVS to be used for
mixed source code, although unless most of the source code is mergeable
text it probably isn't worth it.

> He asked if it's possible for CVS to handle the 01 case. This should 
> invoke knowledgeable discussion about the problems of implementation, 
> not endless flames about "binary" files.
> 
People may just be going a little fast, and assuming that everybody
understands
that, in C, there are text modes and binary modes, not
mostly-text-but-a-little-
bit-binary modes, and that CVS and its internal tools rely on C I/O heavily.
Therefore, if you're talking about something that can't properly be handled
using fprintf() and fgets(), it's binary unless somebody explicitly proposes
a new mode and explains how to put it into CVS.