RE: cvs update; merge

[Greg A. Woods]

[ On Thursday, August 30, 2001 at 23:56:13 (+0200), Peter Ring wrote: ]
> Subject: RE: cvs update; merge
>
> The concept of 'text' vs. 'binary' file I/O may be in the standards for C
> runtime libraries, but it stinks anyway.

Yes, you're absolutely right, but what do you expect from a very
"Western"-centric standards effort that was designed to deal with issues
in primary Western-oriented computing environments?

> 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.

Oh, but there IS, _especially_ with CVS!  If you're stuck supporting a
non-unix platform as *one* of the client platforms for your repository
then the only other way to normalise the files is to disallow any
editing on the client -- force everyone to edit all their files on the
unix server, using unix file editing tools.  The non-unix client hosts
must treat the working directory files as read-only (you can maybe force
this with mount options), and any developer

This does work, but it can be cumbersome and error prone.

> 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).

Win32 doesn't *need* the ^Z, but if I'm not mistaken it will honour it
and will ignore anything past a ^Z in a text file, won't it?  In any
case it doesn't really matter just so long as the C library CVS is
linked against does the right thing for text files on the client host
platform in question.

> 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
> either.

End-of-line translation is *always* necessary on those platforms that do
not conform to the standard unix format.

Character set encodings are more an issue for display and data entry
devices than they are for the filesystem and for diff/diff3.

So, the need for character set translation is far more rare, especially
with source code.

> 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.

You'll have to speak to the RCS maintainers about that -- the
interpretation of '-kb' vs. '-ko', etc. used by CVS comes from RCS.
This is one place where maintaining compatability with RCS is definitely
an imporant issue.

> 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.

You're asking for a nightmare.  You DO NOT want a mix of types of text
files in your repository, whether you know it yet or not.  You really do
want to have a normalised text format in the repository, and if your
repository is a CVS-based one then that format must be a unix-style format.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>