[Top][All Lists]

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

RE: checking in links to source control

From: Alex Harper
Subject: RE: checking in links to source control
Date: Mon, 10 Sep 2001 23:45:37 -0500

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

Understood. Its not the layout I would have chosen, but that's a
different conversation. In our case very few (if any) scripts are
directly tied to an individual data file, and the data files are always
separate from the code. The relationship between the two is documented,
so the user has to RTM before using arbitrary data with arbitrary

Obviously your need to intermingle code and data in the same (or nearby)
dirs changes that. 

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

Yes, we do use the same block at the start of every script. It never
struck me as inelegant since it hasn't changed for some time, and comes
as a part of our standardized header comments anyway.

Of course, your layout is different than ours and apparently requires
many more entry points (scripts) than I would have thought, so the
overhead of maintaining that BEGIN block is presumably higher for you.

> except the fact that the files are in another location 
> outside the project 
> directory and its a pain to trace them down.

As I mentioned in my previous message I'm not here to argue against
symlinks in CVS, just trying to mention a different approach. The notion
that single, presumably well-documented, repository location for
libraries is a pain to find never occured to me. I guess all I can say
is that it works for my application.

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

And MacOS has aliases, etc. Yes, many platforms have similar structures,
although my experience with MS shortcuts is that they are a far cry from
real links. I'm not actually sure if Win32 perl will treat shortcuts as
links when resolving @INC...

My comment was simply based on the fact that my favorite CVS "feature"
is that it is a well-behaved cross-platform citizen, and when clients do
non-standard things (like for example storing MacOS resource forks) they
tend to do so in a way that extends without breaking revision extraction
other platforms. Your proposal would not necessarily "break" other
platforms, but would result in a loss of functionality on those
platforms since they cannot correctly extract the underlying revisions
represented by the links.

It seems to me a more desirable feature for CVS would be to allow
file/directory links within the repository that are not based on
symlinks. While I rarely have a kind word to say about Visual
SourceSafe, it does offer this functionality. So do both StarTeam and
Perforce I believe.
> 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=<path>
> or 
> @link = @env{whatever}/project/bin.

This would obviously be better.


reply via email to

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