[Top][All Lists]

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

address@hidden: Re: checking in links to source control]

From: Edward Peschko
Subject: address@hidden: Re: checking in links to source control]
Date: Mon, 10 Sep 2001 20:43:18 -0700


didn't see you respond to the list, so here goes...

> We have a number of perl scripts stored in CVS which share a large set
> of common library modules. They work exactly as you describe, in that
> they are able to bootstrap themselves onto any machine they are checked
> out onto without any user configuration (except for installing perl
> itself, of course). For our tool the "build" for the tool is just to
> checkout the appropriate module.

Ok, suppose you have a driver script, call it 'bootstrap.p'. This driver script
goes along with a couple of data files (say an ini file and a function 
library that drives the script (call it

Now, where should bootstrap.p live? If it lives in a centralized script 
directory, then it is disattached from the files that are used to drive it, and
its not obvious to the user what they are are supposed to do.

On the other hand, if it lives locally, then its tied to the particular
data files that are running it. And suppose you want to reuse the script
for *another* data file, and have that in *another* directory?

> Access to the libraries is accomplished with a BEGIN block, 'use lib',
> and some '$FindBin::Bin' trickery. No environment changes needed.

And you need to put this FindBin::Bin trickery at the beginning of each script,
right? I've done that before; it works but its not elegant.  It becomes a real
pain to put that block in front of everything - it also becomes a lot more
cumbersome to track down where the libraries actually are.

I mean, if I really wanted to, I could simply put a 'use lib' '../perllib' or
somesuch. I just want to standardize on use lib 'lib' and not have to worry
about any magic, or any other issues.

> Since it seems you have already decided to use a common library location
> anyway, will this not solve the issue? Admittedly it does not result in
> exactly the layout you describe with a "lib" directory below each
> script, but it works equivalently.

except the fact that the files are in another location outside the project 
directory and its a pain to trace them down.
> Of course, its possible I've missed the point...
> Alex
> PS: Though I'm not especially concerned if symlinks become a part of CVS
> or not, I do feel I must point out that your implementation suggestion
> gives me two concerns:
> First it assumes that CVS is a unix-only tool, which of course is not
> true. Not all platforms have a equivalent to links, and its not clear
> what clients for these platforms would be expected to do when they came
> across one of these "magic" link RCS files. Check out the equivalent
> tree? They could, but its not really what you would want, and results in
> file duplication in multiple portions of the tree (files which would get
> out of sync during commits and updates unless additional local CVS
> metadata was stored to emulate the link behavior).

No, I'd say that if you want to use links, you know you are working on a 
platform that supports them. No links, and you get a file that tells you that
its a link.

As for other oses, well, its a bad practice to try to force onto them something
that they weren't designed to use. However, note that microsoft and VMS both 
have 'links' (microsoft just calls them shortcuts)

> Second, it mixes revision metadata (checkin comments) with revision
> content, which in general seems a bad practice to me.

Fine, then make the link a one line file that has a special tag in it to 
signify that its a link - something with the regex:



@link = @env{whatever}/project/bin.


reply via email to

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