info-cvs
[Top][All Lists]
Advanced

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

RE: cvs update; merge


From: Jimm Grimm
Subject: RE: cvs update; merge
Date: Wed, 29 Aug 2001 15:53:23 -0400

        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

        There may be cases where people don't want eol conversions to take
place, yet those files are still mergeable.  For example, I don't want any
binary files to get mistaken for ascii and destroyed, so I put
* -k 'b'
in cvswrappers.  But then cvs won't do any merging, even on my text files,
because it assumes they are binary.  And there are cases of ascii files that
are nonmergeable.
> Examples of such files include Frame Maker MIF documents and uuencoded
files. - Paul Sander

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)

        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.

        Of course this would still not be 100% foolproof, because someone
could name a binary file with a name that is normally used for ascii, or
vice-versa.

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.
moral:   If you are using any binary files across platforms, default should
be binary, not ascii.

Thanks!

Jimm




reply via email to

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