[Top][All Lists]

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

RE: cvs update; merge

From: Peter Ring
Subject: RE: cvs update; merge
Date: Thu, 30 Aug 2001 23:56:13 +0200

Sure it's a sore point, but at least for me, it's getting a new twist.

The concept of 'text' vs. 'binary' file I/O may be in the standards for C
runtime libraries, but it stinks anyway. There's no longer much sense in
inferring a specific end-of-record format from the name of the operating
system that an instance of CVS happens to run on. It's ages ago that tools
on Win32 needed a ^Z for EOF, and a lot of Win32 tools handles any common
end-of-record format (I'm aware that *nix and MacOS tools tend to be more
picky). Why bother translating end-of-records if you do not also translate
between the different character sets that might be used in each sandbox? If
that's not CVS' business, I suggest that end-of-record translation isn't

Some of us do need 'a revised definition of text files'. At least, it should
*not* be coupled to keyword expansion; I may want keyword expansion but no
end-of-record conversion. That way, I could have a mix of LF (*nix style)
and CR/LF (MS-DOS style) files in a project, and everything would just be
preserved without CVS mucking things up. Of course, when processing the
files, I'd have to take care of the CR at the end of lines in MS-DOS style
files, but that's not any of CVS' business; CVS is not a build system AFAIK.

On Win32, I use a Cygwin port of CVS, more or less to the effect that I
want; MS-DOS style files end up in the rep with a CR at the end of each
line, and gets checked out the same - in effect as good ol' MS-DOS files.

I just have to take care 1) not to let anyone use 'native' cvs to check out
those files (that would add an extra CR in their sandboxes), and 2) not to
use 'native' ports of CVS in the same sandbox; the Cygwin cvs port doesn't
like CRs in the administrative files. So I'd like to have an official way of
telling CVS which kind of end-of-record translation to perform (none, CR/LF,
CR, whatever) per file.

And keyword expansion is a separate isue.

Kind regards
Peter Ring

-----Original Message-----
From: address@hidden [mailto:address@hidden Behalf Of
Thornley, David
Sent: 30. august 2001 17:29
To: address@hidden
Subject: RE: cvs update; merge

No, case 01 is not perfectly OK, for very good reasons.


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
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
whatever they are, should keywords be expanded or not?


reply via email to

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