Re: CVS and unicode

[Pierre Asselin]

Christian Hujer <address@hidden> wrote:

> Am Sonntag, 11. September 2005 16:51 schrieb Spiro Trikaliotis:
> > Hello Christian,
> > > And afair cvs on Cygwin does not perform any CR/LF conversion at all.
> >
> > Hm, well... I'm not sure if it is the CVS client on cygwin or cygwin
> > itself (if installed to utilize CR/LF endings), but on cygwin, this
> > conversion takes place.
> Well not for me, but...

I believe Cygwin lets you mount directory hierarchies in "binary"
or "text" mode.  I forget the terminology and the exact details.
One of the two behaves like Unix, the other like Windows.  Whether
CVS translates or not should depend on the Cygwin mount type of
the filesystem holding your sandbox.


> This is not the point of the program but of the file specification.
> If a file specification says "This is a text file. Line endings always have 
> to 
> be LF, regardless of the operating system." an automatic conversion behaviour 
> breaks the file specification.

The behavior you dislike is mandated by the C standard.  When a
stream is fopen()'d with a mode of "r", "r+", "w", "w+", "a" or
"a+" the stdio library is *required* to translate between "\n" in
memory and whaterver the host's line-ending convention is in files.
To suppress the translation you have to fopen() with "rb", "r+b"
etc.  It crops up all over the place, not just in CVS.  For example,
file transfer utilities and Internet protocols.

It would be nice if CVS decoupled keyword expansion, text/binary,
mergeability and line-ending conversion independently of one another.
Right now they are all conflated in the RCS "expand" string and
only a few combinations are supported.  The RCS file syntax allows
arbitrary strings there so it would be possible to extend the
behavior but that might break compatibility with the RCS utilities
(which I regard as a bad idea).


-- 
pa at panix dot com