[Top][All Lists]

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

RE: Forcing DOS line endings on checkout/update

From: Thornley, David
Subject: RE: Forcing DOS line endings on checkout/update
Date: Wed, 1 Aug 2001 10:40:26 -0500

> -----Original Message-----
> From: Alleman, Lowell [mailto:address@hidden
> > -----Original Message-----
> > From:       address@hidden [SMTP:address@hidden
> > 
> > With CVS You have two, and exactly two, viable, 
> incompatible, options:
> > 
> >    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.

If it's on NT, can't you run c/s with the client on NT and the server
on whatever?  If the files live on NT, and people work on NT, there
shouldn't be any problems.

> 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.
I'm not sure this is the best way to use CVS, but it's your shop.

> 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.

There are good reasons against putting line-ending translations in
CVS.  We discussed this a while back on the list.  There is no well-
defined proper way to translate, and there are enough tools that can
do the job independently of CVS.  Would it be possible to use one
of those tools?

> 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.  
This isn't just extra command-line parameters, but extra functionality.
Right now, CVS has no code to do such transformations, but uses the C
library's I/O functions.  Since these handle line endings differently on
Unix, Windows, and Mac, the CVS client code automatically handles the
local line ending conventions.

In order to use different conventions, it would be necessary to open the
files as binary and duplicate the text-mode functionality of every supported
system.  This can be done (and has been, in other applications), but it
is a nontrivial change.  It would be necessary to agree on what to do and
for somebody to do it.  So far, it doesn't seem to have annoyed anybody
enough to make them submit a proper patch, and there haven't been enough
complaints to make any of the more active developers do anything.  This
is GPLed software, not Microsoft.  Your requests for change will at least
be ignored more personally (if sometimes less professionally), but there's
alway the "Use the source, Luke!" option.  (Is Visual C++ useful in an
ISO-conforming manner currently?  If I were a Windows C++ developer, that
would be my #1 complaint.)

> > > 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.
> > 
They may, and may actually share your opinion about real-world needs.
At a glance, it looks like Subversion will assume binary mode more readily,
but I didn't see anything about incorporating line-ending conversion.

> > 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.
> > 
And now for something completely different....I completely agree with what
Greg has written above.  (I don't think I've said that in some time.)

reply via email to

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