[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Forcing DOS line endings on checkout/update

From: Bruce Hill
Subject: RE: Forcing DOS line endings on checkout/update
Date: Tue, 31 Jul 2001 19:09:42 -0700

Since you're presumably running a mix of Win32 and Unix machines
one solution would be to mount your Unix directory on your Win32 box
and use Win32 based CVS.  Since the Win32 CVS converts text files to
DOS line endings, this might be all you need.  You can download Samba or
purchase an NFS client to mount your Unix directory.

We have a similiar problem here.  We need some files, such as Win32 batch
files, to retain their DOS line endings.  Other files, particularly Unix
shell scripts and makefiles, need to retain their Unix line endings.  We
also have files, Word docs, libraries, and other binaries, which we use
the -kb flag to mark as binaries.  We have a mix of users on Win32 vs Unix
machines, with some using both as we target both platforms.

The default for our Win32 based CVS tools is to convert non-binary files
to DOS line endings.  While all our Unix and Win32 source code editors can
handle either line ending, it really messes up diff comparisons if someone
accidently converts the line endings on a source file and commits it from
the other platform.

Our best solution, since the basic CVS doesn't support this, is to use WinCVS
for our Win32 CVS operations.  It has a "Checkout text files with the Unix LF"
option which we select.  What this actually does is suppress the line conversion
which Win32 based I/O performs, probably by opening files as binary instead
of text.

The other solution you might try is to convert all your text files to Win32
line ending with a unix2dos or similiar utility.  Then commit them using
Unix based CVS tools and perform your CVS operations using only the Unix CVS.
The Unix based CVS doesn't mess with the line ending, preserving whatever line
ending you commit.

More explicit control over DOS/Unix line ending conversion is on our
wish list of CVS features as well, although we're looking to suppress it
instead of forcing DOS line endings.

- Bruce Hill

> From: "Alleman, Lowell" <address@hidden>
> To: 'Eric Siegerman' <address@hidden>, "CVS Mailing List (E-mail)"
>        <address@hidden>
> Subject: RE: Forcing DOS line endings on checkout/update
> Date: Tue, 31 Jul 2001 14:43:38 -0400
> So were talking about either modifying the CVS source code, or linking to a
> modified library......right?
> I have a hard time believing that no one else has needed this feature
> before. I'm surprised that there isn't some environmental variable that you
> can just set, like 'CVS_ENV=DOS' which would setup the end of line modes.
> Any ideas on the safest way to set this up without modifying CVS or the
> libraries that it is linked to?  Has anybody else run up against this issue?
> > -----Original Message-----
> > From:       Eric Siegerman [SMTP:address@hidden
> > Sent:       Tuesday, July 31, 2001 1:45 PM
> > To: CVS Mailing List (E-mail)
> > Subject:    Re: Forcing DOS line endings on checkout/update
> > 
> > On Tue, Jul 31, 2001 at 11:35:07AM -0400, Alleman, Lowell wrote:
> > > Is it possible to force cvs to use DOS line endings on a Unix-based
> > machine?
> > 
> > It's not CVS itself, but rather the underlying C library, that's
> > responsible for this conversion.  CVS just goes "putchar('\n')"
> > (or fputs() or printf() or whatever), and the I/O routines
> > translate that into the system's local convention (on Unix, of
> > course, no translation need be done).
> > 
> > So it's not simply a matter of "turning on" an existing
> > translation scheme, because there isn't one; it'd have to be
> > written.
> >

reply via email to

[Prev in Thread] Current Thread [Next in Thread]