RE: checking in links to source control

[Alex Harper]

Sidestepping the issue of links in CVS, I'm unclear on the problem
you're trying to solve.

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.

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

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.

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

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



> -----Original Message-----
> From: Edward Peschko [mailto:address@hidden
> Sent: Monday, September 10, 2001 8:32 PM
> To: CVS-II Discussion Mailing List
> Cc: address@hidden
> Subject: Re: checking in links to source control
> 
> 
> On Mon, Sep 10, 2001 at 06:03:53PM -0400, Greg A. Woods wrote:
> > [ On Monday, September 10, 2001 at 13:33:57 (-0700), Edward 
> Peschko wrote: ]
> > > Subject: Re: checking in links to source control
> > >
> > > 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*.
> > 
> > Nope.  BZZZZZT.  Wrong.  CVS is not a build system.  Get a 
> new paradigm.
> 
> I beg to differ. Why should it *not* be a build system? One 
> of the hallmarks 
> of creativity is to be able to use existing tools in new and 
> interesting ways.
> Trying to shoehorn a role for a tool simply because it doesn't fit a
> preconceived view of what a tool should or should not be 
> ain't very smart.
> 
> And why should I 'get a new paradigm'? The process of making 
> checkout and build
> one and the same has tremendous benefits - especially if you 
> are dealing with
> interactive, non-compiled languages. Methinks I smell a bit 
> of compilation 
> prejudice here...
> 
> > (You might be able to hack something together with a script run on
> > checkout, but the last time I tried that it was a major 
> nightmare to get
> > right, and to maintain.)
> 
> Hence my desire to make cvs work with links. It would be easy 
> enough - all you
> would have to do is recognize a certain tag on checkout 
> corresponds to a link.
> and create a link instead of a file.
> 
> > > CVS should have link support.
> > 
> > Nope.  BZZZZZT.  Wrong again.
> 
> please stop that childish 'BZZZZT' stuff. Its both 
> unprofessional and rude.
> 
> > There's an almost infinite supply of rationale for this 
> decision in the
> > archives too, not the least of which is that RCS can't do 
> it either, and
> > any scheme you might dream up should: a) work with bare 
> RCS; and b) work
> > in such a way that a name in the filesystem can exist, at different
> > times, as a normal file, or a link, or a hard link.  I'll bet you'll
> > find meeting those requirements nearly impossible.
> 
> Well, there are two levels of compatibility possible with RCS:
> 
>       1) complete compatibility, where there is a one-to-one 
> mapping between
>          an RCS term and a CVS term.
> 
>       2) compatibility where an RCS directory created by CVS 
> doesn't freak
>          out when used by CVS.
> 
> If you are talking about definition #1, then well, we are in 
> real trouble 
> because CVS is a superset of RCS and going back and forth 
> between the two
> is a lossy business.
> 
> If you are talking about definition #2, then there is a real 
> simple way to make
> link support 99.9% backwards compatible:
> 
>       1) if 'adding' a link, make a one-line comment for the 
> file revision,
>          that defines where the link points to.
> 
>       2) when checking out that link, look for that comment. 
> If it is a link,
>          when checking out, make a link. If not, make a file.
> 
>       3) if checking in a link (committing it) follow the 
> link to commit the
>          real file instead (if it exists in CVS). If it does 
> not exist in 
>          CVS, error out.
> 
>       4) as far as diff goes, etc - if one is updating a link,
>          follow that link to the real file and patch that 
> instead. If the 
>          real file does not exist, or is not found in CVS, error out.
> 
> All of #3 and #4 is done at the level of the client, ten or 
> maybe less lines 
> of code necessary.  All your talk is really just bluster IMO 
> - I've *done* 
> stuff like this, around RCS, and it really ain't that hard. 
> It should be 
> fairly trivial to add to CVS.  I bet that the resulting patch 
> would be about 
> 100 lines long, if even that, and you'd get an exceedingly 
> consistent interface.
> 
> > Nope.  BZZZZZT.  Wrong yet again!   Where the heck did you get that
> > idea?  RTFM, for starters (specifically the nodes "What is CVS?" and
> > "What is CVS not?")
> 
> I realize the danger of trying to be everything to everybody 
> - but you've got
> to admit that links are a fairly trivial thing to add. If 
> not, point out holes
> in my implementation above.
> 
> There are real dangers in making decisions to the design of 
> products based on
> dogma. I smell religion here. Its in both the arguments you 
> state, and the 
> tone in which you state them. 
> 
> In short, I am not asking for CVS to have a complete 
> full-blown build system.
> I am asking for CVS to help *support* a build system, the 
> same way that 
> recursive updates supports a build system like make.  The 
> build system in 
> question here is perl.
> 
> Or do you want to rip out recursive updating because it 
> smells too buildlike?
> 
> Ed
> 
> (ps - sorry for the sarcasm here. But I promise to take it 
> down a notch if 
> others on the list do. I just don't like being patronised.)
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
>