Re: checking in links to source control

[Greg A. Woods]

[ On Monday, September 10, 2001 at 18:32:06 (-0700), Edward Peschko wrote: ]
> Subject: Re: checking in links to source control
>
> I beg to differ. Why should it *not* be a build system?

CVS is a version control system.  It does not build things -- it only
tracks changes to things (usually just text source files at that).

Use the right tool for the job.

> One of the hallmarks 
> of creativity is to be able to use existing tools in new and interesting ways.

Hmmm.... maybe you should take a look at 'make'.  It can be used to
create your symlinks in any number of different 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.

Well, you could shoehorn perl itself into being your build tool.  A
simple little script run after the initial checkout should work just
fine.  Hopefully you'll include the script in your source module so that
changes to it too can be managed by CVS.

> And why should I 'get a new paradigm'?

Because you seem to be thinking with the "I have a hammer in my hand"
mindset, and that's a very unproductive thing to do in software
engineering.

Besides, you really should be using "cvs export" to create the source
tree from which you build the target product you're working on.  That's
not to say you can't install and run it from a working directory, but
you sure as heck don't want to be using the contents of any working
directory to build the final product you ship to your customers!  CVS
can only ensure a proper clean result with "cvs export" using a release
tag.

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

Methinks you really do have a penchant for using the wrong tool for the
job.....

Indeed I think you've also got a bias towards believing that you don't
have to "build" something that doesn't need to be compiled into object
code and assembled into machine code to run.  Nothing could be further
from the truth, especially with a version control system like CVS.  CVS
manages your source files.  You have to manage any transformation
necessary to turn them into product files (or find some other tool to
assist you with that task).

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

I think you vastly underestimate the complexity of the task.  A link is
a file that contains a pathname.  You could add a flag to the RCS file
format to specify this attribute, but the trick is doing it in a way
such that the presence or absence of this attribute is specific to each
revision of the file.  You can't just assume that a given name in the
filesystem hirarchy of your code module will always be either a normal
file or a symbolic link.

However for all the talk of modifying and extending the supposedly
extensible RCS file format, I've yet to see any running code as an
example.

> please stop that childish 'BZZZZT' stuff. Its both unprofessional and rude.

Sorry, but this topic is just so old and boring that I've got to do
something to keep myself amused or else I'd be far more rude and
inconsiderate.

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

There's no sense doing anything but #1, especially for a feature like
this.  It's not an impossible thing to ask -- but it does seem to be
more difficult than anyone's yet offered to take on.

Remember one primary essence of elegance in computer programming is to
never make anything more complex than necessary.  CVS is quite elegant
in many ways because it leave special and rare cases to be dealt with
externally where their solutions can individually achieve their own
elegance.

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

Support for symbolic links is not "trivial" to add to CVS.  If it were
such a thing would have been done way back before 1.5 when I first
naively suggested the very same thing.

Other than that you're absolutely right.  CVS cannot be everything to
everyone.  Symbolic links are trivial to create and maintain external to
CVS using anything from a simple interpreted script in the language of
your choice, through to a makefile, or even pretty much anything more
sophisticated.

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

CVS does support "a" build system -- in fact it easily supports many
diverse kinds of build systems.  It does this by keeping the hell out of
the way of them!  (well it's not perfect, it can confuse trivial build
systems such as unix make by doing unexpected things with timestamps,
but there are compromises necessary in this kind of thing....)

> the same way that 
> recursive updates supports a build system like make.

Huh?  What strange ideas you have!

Make doesn't need recursive updates!  Heck make doesn't even need any
version control system, and you can certainly manage source files for
input to a make-driven build system using pretty much any version
control tool, even ones that work on only one file at a time.  In fact
traditionally Unix make *was* the recursive update system when used with
bare SCCS (and later RCS) which worked in place of a multi-file version
control tool like CVS by using simple make rules, often included in the
system-wide initialisation file for make (and sometimes with one silly
little built-in hook to pull the initial makefile itself from SCCS).

Note also that many people consider recursive make an evil, dangerous,
and/or very in-efficient thing too!  See, for instance these two pages:

        http://www.canb.auug.org.au/~millerp/rmch/recu-make-cons-harm.html

        http://www.perforce.com/jam/jam.html

>  The build system in 
> question here is perl.

fine.  then write a perl script to create your symlinks.


Speaking of using the right tool for the job though -- if you want to do
rapid development why don't you use a fully integrated IDE and a
language truly suited to rapid development, such as a Smalltalk system?
Squeak is a full smalltalk-80 implementation with multi-media extensions
(can be used as a multi-threaded server), network support, which is fully
multi-platform, and it's free too!

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>