Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 21 Dec 2003 21:56:40 +0000 (GMT)
From:      Jan Grant <Jan.Grant@bristol.ac.uk>
To:        Doug Lee <dgl@dlee.org>
Cc:        freebsd-questions@freebsd.org
Subject:   Re: FreeBSD CVS for DOS/Windows sources?
Message-ID:  <Pine.GSO.4.58.0312212152250.684@mail.ilrt.bris.ac.uk>
In-Reply-To: <20031221200556.GR15420@kirk.dlee.org>
References:  <20031221172552.GQ15420@kirk.dlee.org> <200312212058.30951.dgw@liwest.at> <20031221200556.GR15420@kirk.dlee.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, 21 Dec 2003, Doug Lee wrote:

> On Sun, Dec 21, 2003 at 08:58:30PM +0000, Daniela wrote:
> > On Sunday 21 December 2003 17:25, Doug Lee wrote:
> > > I'm trying to use FreeBSD's CVS (v1.11.5) to manage DOS/Windows
> > > projects, which of course means files with CR/LF line endings.  The
> > > docs claim the repository will internally store everything (text files
> > > anyway) with only LF endings, but in fact I'm seeing CR/LF endings in
> > > repository text files.  This is still fine until I pull a project out
> > > with a DOS/Windows CVS client (the standard cvs.exe), which gives me
> > > lines ending in CR/CR/LF.  If I pull the project under Unix, I get the
> > > CR/LF endings just fine; but my coworkers will not be telneting to
> > > Unix just to pull code...
> >
> > I don't know anything about Micro$oft Winblows eXPensive, but why don't you
> > just strip the CR on the server? So the Windoze client can add the CR, and
> > you always get the native format, respectively.
> > This is definitely the fault of the client, so don't blame the server :-)
>
> Actually I wasn't sure whose "fault" it was, since the docs say the
> CR's should not be stored by the server.  Given that, the client did
> what it should under the circumstances.

If the file is stored in text mode, the _client_ does line-ending
conversions according to local conventions. The server expects the files
to be in the unix \n-terminated format.

So the problem is actually the "fault" of the unix client since it
"knows" that it doesn't need to do any CRLF translation on upload.

You see this a lot when using Unix CVS to deal with windows-originated
files. Your options are either to do the first import using a windows
cvs client, or to correct the line ends (eg, with dos2unix) on the unix
cvs client prior to upload.

Once the files are correctly formatted on the server, both unix and
windows clients will be able to deal with them correctly.

> I didn't edit the repo because I don't consider myself savvy enough
> about CVS yet to start playing with repo files directly, except to
> look at them with a curious eye.

For text files, they're line-oriented. The server itself will not insert
any '\r' characters, so any that are in your repo files definitely came
from a borked upload. You should be able to strip them out and
re-checkout the files: diffs will be unaffected.


-- 
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/
There's no convincing English-language argument that this sentence is true.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.58.0312212152250.684>