|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:
> > 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!)
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.
|[Prev in Thread]||Current Thread||[Next in Thread]|