RE: Forcing DOS line endings on checkout/update

[Kostur, Andre]

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