info-cvs
[Top][All Lists]
Advanced

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

Re: Forcing DOS line endings on checkout/update


From: Greg A. Woods
Subject: Re: Forcing DOS line endings on checkout/update
Date: Wed, 1 Aug 2001 01:39:41 -0400 (EDT)

[ On , July 31, 2001 at 20:20:10 (-0400), Laine Stump wrote: ]
> Subject: Re: Forcing DOS line endings on checkout/update
>
> They have needed it. And every time they bring it up on this mailing
> list, it is shot down by people who don't want/need it, and therefore
> insist that it is a silly idea.

NO!  That is NOT the reason why such a feature is rejected by
experienced CVS users and maintainers!  It is not that it's a silly idea
per se -- it's more along the lines that there simply is no possible
correct solution that'll keep everyone happy all of the time.  There
isn't even anything close to correct.  Any attempt to solve the problem
in the way suggested will simply cause more problems and complaints.

The real reason was just re-explained again quite clearly in this very
thread very recently.  Oh, and look at that -- you quote a bit from the
very message in which it was explained!

> Mike Castle <address@hidden> writes:
> >  
> > CVS always has (and hopefully, always will!) used the default text mode of
> > the system it is running on.
> > 
> > If you want it to check out things in DOS format, then run it on a machine
> > that supports DOS format natively.
> 
> Sometimes that isn't practical, or isn't convenient, or you just plain
> don't remember which platform you were running on when you did the
> initial checkout (CVS informs you that you've done a subsequent
> update/diff/commit/etc in different cryptic ways (ie "mysteriously
> croaks with an unrelated message") depending on what the original
> platform and the current platform are).

I'm sorry, but if that's not practical then either you're using CVS in
very inappropriate ways, or you shouldn't be using CVS in the first
place.

With CVS You have two, and exactly two, viable, incompatible, options:

1. DO NOT SHARE WORKING DIRECTORIES BETWEEN DIFFERENT TYPES OF
   SYSTEMS!!!!!!  (that's one of the reasons CVS has client/server
   support in the first place, ya know!)

2. NEVER RUN CVS ON ANYTHING BUT THE CVS SERVER (and instead share your
   working directories using network filesystems, or with scp, etc.)

Mabye "cvs checkout" should store "uname -srm" (or the equivalent) in
CVS/platform and refuse to do anything at all if there's not a
relatively close match between the stored value and the current runtime
value.

Of course CVS is only at the tip of the ice-burg of problems you'll
encounter if you try to edit (and sometimes otherwise process) the same
text files with native editors on different types of systems, so #1 is
probably the best alternative for most people, though of course it won't
solve any of the other issues that need to be dealt with in multi-
platform development.  These other problems are also why #2 above will
probably cause more headaches than it solves, even if every developer is
perfectly happy with using CVS directly on the server and only on the
server.  At least with #1 the platform-specific CVS clients can
re-mangle line {termin,separ}ators into Unix form for the server to
store.

> I tired of the debate after the 2nd or
> third time, and am now just waiting for Subversion to go gold - maybe
> the people there will be more reasonable wrt real-world needs.

BTW, no other system of sharing files and tracking changes made to those
files on different systems will ever avoid these issues cleanly for all
people at all times either -- there's always going to be fundamental
unresolvable conflict when three or more different and incompatible
systems are invovled.  The best you can do is reduce the problem to a
one to many scenario (instead of many to many), and that's what #1 above
will do implicitly.

Note that these issues are really no different from those encountered
when developers fight over tab size and try to re-format each other's
code so that comment columns on the right of indented code always line
up.  It simply cannot be done.  This is why experienced people learn to
adhere to coding style guides even though it might force them up a
learning curve they didn't want to climb.  When a project spans
platforms with differing conventions its style guide should also define
which line ending/separating scheme is to be considered "correct" for
the given project, and if necessary what algorithm will be used to
translate formats where necessary for handling by platform specific
tools.  This may, or may not, put requirements on where (i.e. on which
type of platform) code is edited on, and/or what editor is used too.
Get used to it, or drop out of doing multi-platform development.

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>



reply via email to

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