[Top][All Lists]

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

RE: Forcing DOS line endings on checkout/update

From: Kostur, Andre
Subject: RE: Forcing DOS line endings on checkout/update
Date: Wed, 1 Aug 2001 07:53:16 -0700

> -----Original Message-----
> From: Alleman, Lowell [mailto:address@hidden]
> Sent: Wednesday, August 1, 2001 6:41 AM
> To: 'address@hidden'
> Subject: RE: Forcing DOS line endings on checkout/update
> > -----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:
> >
> >    SYSTEMS!!!!!!  (that's one of the reasons CVS has client/server
> >    support in the first place, ya know!)
> >

Lookout, the world's going to end, but for once I agree with Mr. Woods.  Maybe not his style of presenting it, but the content makes sense.  Working directories should never be shared.

> I'm not making a "WORKING" directory.  The "shared" copy will
> end up on a NT

If it's not a working directory, shouldn't it be "export"ed ?

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

Easy enough to enforce the use of CVS.  The production system _only_ gets it's files from CVS.  Users do not have any access to drop in random files, they _must_ be committed to CVS before the production systems will see the files.

A different question, why not have the NT users checkout/update the appropriate modules from CVS when they're interested?

> 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

Speaking of scripting, what about running a post-export script which would convert the offending files to have CR/LF?

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

Well, creeping featurism is one reason to not add it in.  That's yet another bit of code that can screw up in future releases.

reply via email to

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