Re: GWindows and David Botton

[kaz@ashi.footprints.net (Kaz Kylheku)]

Stephen Leake <stephen_leake@acm.org> wrote in message news:<mailman.199.1097016199.390.comp.lang.ada@ada-france.org>...
> Ludovic Brenta <ludovic.brenta@insalien.org> writes:
> 
> > I cannot help but think that CVS is the "C" of revision control
> > systems.  Ada programmers deserve better than that :)
> 
> I hadn't thought of it quite that way :).
> 
> > With Meta-CVS, one can get the best of everything: the SourceForge
> > CVS server and surrounding tools, without the annoying CVS
> > deficiencies.
> > 
> > At least, I think Meta-CVS is worth a look.
> 
> If Meta-CVS is a purely client tool, then each developer can use it or
> not; it doesn't have to be a project-wide choice.

Such a tool can't do the things that Meta-CVS can do. People have
played around with scripts to do things like simulate renaming over
standard CVS projects that can be fully checked out with a regular
client.

In the Meta-CVS project, I did not want to aim the guns that low into
the ground, but rather elevate the muzzle above the horizon.

I just wanted to reuse all of the behaviors that CVS does reasonably
well: namely keeping a vector of text documents synchronized between a
remote repository and a local sandbox, with support for parallel
editing, branching and merging.

In order for an element of this vector to retain its identity, while
changing its name and position within the filesystem tree, it is
necessary to represent that name and position as a separate property.
The name, as known to CVS, then just becomes an abstract identifier,
which might as well be based on some 128 bit number or something like
that.
 
The question is where to store the name? The simplest answer is to
store it in some other file which can also be versioned, and subject
to branching and merging.

This way, when you check out the database, all you have to do is parse
this file, and arrange the rest of the documents into a tree, which
can be done using efficient hard-linking operations, rather than bulk
transfer of data.

In fact, what Meta-CVS does is keep a farm of hard links so that it
has the original vector as checked out by CVS. CVS checkouts and
updates take place in this farm area. A restructuring algorithm
reshapes the tree by looking at the differences between the current
structure and the newly desired version. A simple synchronization
algorithm repairs any broken hard links between the tree and farm.

> I already use CVS for _everything_. While in general I'm in favor of
> learning new tools, in this case I'm sticking with CVS.

Meta-CVS is my way of expressing essentially the same attitude: I'm
sticking with CVS! Only I'm going to make it jump through hoops that
over years of CVS mailing list discussions declared impossible, that's
all. ;)