RE: Forcing DOS line endings on checkout/update

[Alleman, Lowell]

> -----Original Message-----
> From: address@hidden [SMTP:address@hidden
> Sent: Wednesday, August 01, 2001 1:40 AM
> To:   address@hidden
> Cc:   CVS Mailing List (E-mail)
> Subject:      Re: Forcing DOS line endings on checkout/update
> 
> 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!)
> 
I'm not making a "WORKING" directory.  The "shared" copy will end up on a NT
share with read-only access for all NT users. (Except for the user
responsible for running updates which is necessary to keep the files up to
date with the repository.)  The idea here is to use CVS as an interface for
modifications -- providing a more standardized way for our developers to
enter log messages for historical purposes -- instead of just allowing the
developers to access the NT share directly, make any changes they want, and
walk away without recording any information about who/what/when/why changes
were made.

Fortunately, most of the stuff were are doing is binary (Oracle
forms/reports, image files...).  So this whole text Unix/DOS line ending
issue should be minimal, but I was trying to do it "right", and I really
thought that this functionality would have already be included.

I know that I could keep the copy in sync on the NT side using scripts, but
I would much rather do this on the Linux side.  NT has no built in scripting
functionality (or none that I'm familiar with beyond the pathetic "batch
files"), and I'm not going to suggest installing Perl or any thing else
which is not completely necessary.  I really hesitate to install any
software on the NT side;  I am trying to convince my coworkers and boss that
implementing cvs will be quick and easy (and integrate well with our current
system); however, that becomes a lot more difficult if I have to tell them
that we have to make modifications to our existing/production NT server.

I understand and agree that, under normal, it is not good practice to allow
what I'm requesting -- the ability to checkout files on OS "A" as if we were
on OS "B" -- but I guess I don't understand what the harm would be in adding
a few extra environmental variables or command line parameters to define
special circumstances as long as the documentation clearly states that these
options are only for rare circumstances and describes the more accepted way
to do the proposed task.  


> 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>
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs