$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-08-08 17:24:59
> > I don't understand; it would help if you could rephrase using CVS
> > terminology - my WinCVS client has "commit" or "update" commands, but no
> > "upload" that I'm aware of.
> >
> > By "upload a file that has Windows line endings from a Unix CVS", do you
> > mean "commit a file that has Windows line endings to a CVS running on a
> > UNIX system"?
> >
> > Or maybe "update a file that has Windows line endings from a CVS running
> on
> > a UNIX system"?
>
> If I understand him, then both.
>
> > Both of those operations happen all the time, yet don't modify line
> > endings.
>
> The problem occurs when a file on Unix has DOS line endings. This should
> rarely occur, since checking a file out of CVS will usually convert line
> endings to the native Unix type. But say you work in both environments and
> you transfer a file from your Windows box to the Unix box with some
> mechanism that doesn't conver the line endings, such as a binary FTP (just
> one of many examples possible here). You then commit or update CVS with
> this file and you get \r\r\n.
>
> At least I think that's what he's describing.
If I have a file with DOS line endings (e.g. \r\n) that I wrote on a Windows
box, then transferred that file to a Unix box and commited it with CVS, CVS
won't convert the line-endings to plain (\n). When that happens, you end up
with \r\n line-endings on the CVS server, which is not supposed to happen.
Consequently, if you checkout (or update) with CVS from a Windows box, CVS will
obliviously replace the '\n' in '\r\n' with '\r\n', which will give you the
grand result of '\r\r\n'.
Paul Mensonides