[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: cvs update; merge
From: |
Larry Jones |
Subject: |
Re: cvs update; merge |
Date: |
Wed, 29 Aug 2001 16:31:28 -0400 (EDT) |
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
- Re: cvs update; merge, (continued)
- Re: cvs update; merge, Larry Jones, 2001/08/29
- RE: cvs update; merge, Jimm Grimm, 2001/08/29
- RE: cvs update; merge, Jimm Grimm, 2001/08/29
- RE: cvs update; merge, Jimm Grimm, 2001/08/29
- RE: cvs update; merge, Andreas Lindgren, 2001/08/30
- RE: cvs update; merge, Thornley, David, 2001/08/30
- RE: cvs update; merge, Thornley, David, 2001/08/30