Re: Source version control (Was: [9fans] lucio-)

Re: Source version control (Was: [9fans] lucio-)

[Fco.J.Ballesteros]

Why don't you just change the implementation of the file server
to accept a remote 'dump name' command to cause an immediate dump at root
/n/dump/name/ ?
Of course this would need to implement something like a /ctl file
on the file server to accept innocent-looking(?) commands from other machines.

Source version control (Was: [9fans] lucio-)

[Lucio De Re]

On Thu, Jan 10, 2002 at 10:37:55AM +0000, Bruce Janson wrote:
>
> dump wins out over the SCCS/RCS/CVS per-application approaches by
> including more of the environment: e.g. compiler, system includes.
> (In practice, has this been a significant win at the Labs?)
>
They address two different problem spaces, with solutions appropriate
to each.  That's my issue all along: is there a generic approach
that will satisfy a majority of version control needs, or do there
have to be mutually exclusive solutions for a wide range of project
types?

> Two of the limitations of dump are its coarse granularity and its
> arbitrary timing.  To eliminate these one could extend dump by
> allowing anybody to force (and annotate) a dump snapshot.

I hesitate to call the timing arbitrary or, for that matter, coarse,
because it reminds me of arguments about the real time nature of
computer response: throw enough power at it and you can approximate
the ideal as closely as you like.  Which in itself raises some
interesting considerations.

But the automatic nature has both benefits and disadvantages: on
the one hand it guarantees that history is retained and on the
other it allows the user to abrogate all responsibility for doing
so.

The real downside is that annotation, which, as mentioned here in
connection with the changelog, is extremely useful, becomes an even
greater burden for programmers, who are already notorious for
disliking the generation of documentation.

Naturally, the picture painted above is simplistic, but it covers
the most pertinent issues of source control: the retention of as
much information as possible.  In this category we can also include
the labelling of releases and, without the doubt, details of the
broader environment in which the change occurred.

A last note about the environment, while I think about it: /n/dump
provides a pretty good boundary, but certainly too wide to be
practical for a distributed programming project (think Linux).  In
CVS, the boundary may well be too tight (yesterday's problem with
CVS and APE is a case in point).  At the very minimum, there may
be a need to provide a boundary that is more relaxed than the CVS
"working directory", alternatively software developers may have to
be able to include in the concept of a "workspace" any modules
outside of the working directory that have been altered during
development and at the very least annotate the history accordingly.
The option to provide local copies of the environment with each
and every working directory is just too impractical, if not downright
insane (yet, ghostscript, ssh and others all include a copy of zlib
sources in the source distribution archives).

++L