|
Boost : |
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk