Re: checking in links to source control

[Edward Peschko]

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