Re: cvs update; merge

[Larry Jones]

Jimm Grimm writes:
> 
>       I've been reading the mailing lists a bit more on the binary file
> issue, and it seems to come up a lot.  It seems to me like people have often
> merged two separate issues together:
> 
> 1) eol conversions
> 2) mergeable and nonmergeable files

The situation is far more complicated than that.  Eol conversion is but
one aspect of text vs. binary files -- there are lots more.  And it
doesn't help that CVS conflates binary/text with keyword expansion mode,
although one can argue -- quite successfully, in my opinion -- that
binary files by their very definition don't contain keywords that should
be expanded.

> 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
> 
>       Currently, 11 is the default option for all files.  It is possible
> to do 00 on selected files using cvswrappers.  It is also possible to make
> 00 the default option by specifying * -kb in cvswrappers, yet still specify
> some files to be ascii (11)
> (http://mail.gnu.org/pipermail/info-cvs/2001-August/019343.html)

It is also possible to get unmergeable text files (10) by specifying 
-m COPY in cvswrappers.  It's also possible to *specify* mergeable
binary files, but CVS doesn't pay any attention -- it always treats
binary files an unmergeable.  But note again that it's text/binary, not
eol conversion/no eol conversion.  As far as CVS is concerned, the
difference is just whether the file is opened in text mode or binary
mode; exactly what that means and what kinds of conversions are or
aren't done in each mode is solely up to the C Run-Time Library on each
platform, not CVS.

>       Would it be possible to generalize the cvswrappers file to the other
> two options, 10 and 01?  How far could this go towards resolving this raging
> debate?  If someone just adds two more options to cvswrappers, it should
> still be backwardly compatible.

The file format already allows it.  Changing the code wouldn't be hard. 
How useful it would be is hard to say.

> Also note: default treatment as ascii (11) is more dangerous, because if a
> binary file gets mistaken for ascii, it could get destroyed.  On the other
> hand, if an ascii file gets mistaken for binary, it can easily be fixed up
> with dos2unix or unix2dos.

On your platform.  On other platforms, treating a text file as binary is
every bit as fatally wrong as treating a binary file as text is on DOS.

> moral:   If you are using any binary files across platforms, default should
> be binary, not ascii.

Real moral: Don't use CVS for binary files.

<Insert Greg Woods's usual anti-binary rant here.>

-Larry Jones

I think grown-ups just ACT like they know what they're doing. -- Calvin