info-cvs
[Top][All Lists]
Advanced

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

Re: checking in links to source control


From: Edward Peschko
Subject: Re: checking in links to source control
Date: Mon, 10 Sep 2001 13:33:57 -0700

On Mon, Sep 10, 2001 at 11:41:22AM -0400, Jeff King wrote:
> How does something that "implies a build system" have a drawback "as far as
> maintainability"?

Ok, let me clarify myself a bit. I am working in a Rapid Application Development
Environment where compilation is not an issue. 

In such an environment, visibility and speed is key - what I was saying about 
the build system detracts from *these* factors. Only the copying of files around
has a drawback as far as maintainability is concernt.

I want developers to see - locally - all of the perl libraries cross project.
When I do a release, I want people to do a simple 'cvs checkout' to get the 
entire project, and have it *work on the spot*. I want them to be able to
'cd lib' into any project and get to the point where the libraries are stored.
As in:

        perllib/

        project1/
                lib -> /perllib
        project2
                lib -> /perllib

I don't want people to need to set an environmental variable to point to the
libraries, (that I need to put inside scripts), I don't want people to need to 
cd out of a directory to get to the libraries, I don't want people to need to 
go through any hoops in order to get their environment to work.

CVS should have link support.  Saying that it shouldn't is tantamount 
to saying that 'links are a bad idea' inside of archives. Yet CVS purports 
itself to be a generic mechanism for distributing projects like tar or 
compress - I see it used to distribute mozilla, for example - if it is to be 
true to this calling, it should support links.


Another case. Say I have a script that is usable across multiple projects.
Should I have one centralized copy, do a build process to make it magically 
available by path for the data files that exist in a project directory, or 
should I make it visible to each of the projects that I'm working on? With 
only a centralized copy, it requires environment settings, wrapper scripts, a
nd a whole bunch of crap that is totally unnecessary just to make it work.

My solution, via links would allow you to do both - I would 
link the needed file so that I can say:

/perl_module
        script.p

/project_that_uses_script
        script.p -> /perl_module/script.p

/project2_that_uses_script
        script.p -> /perl_module/script.p

And hence, I could say:

        perl script.p <args>

in any one of my subprojects - yet when I edited the file, (and did a cvs 
commit on any of the links) the changes would go into source control.

> Setup a Common or PerlCommon module in your repository. Control the
> Config::INI in that module. This makes it clear that the file doesn't belong
> to a specific project and doesn't require multiple global copies or a shared
> network drive.

yes, that's part of the solution. I was planning on doing that anyways. What
I want is a link in the other directories *pointing* to that. Then it becomes
clear that the file doesn't belong to a specific project because its a link,
not a file.

Anyways, and more to the point:

        1) CVS does not support links, correct?
        2) if I submitted a patch to allow CVS to do this, would that patch be 
           accepted?

Thanks much, 

Ed



reply via email to

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