[gentoo-dev] CVS alternatives -- meta-cvs

[Grant Goodyear]

A recent thread discussed alternatives to CVS.  As our developers know
all too well (but some -dev readers may not), the portage tree is kept
in CVS, which serves us reasonably well until somebody wants to move
files around, rename files, or create symbolic links, all of which are a
real hassle.

I've been casually looking into alternatives for a while, and it's still
not clear that there is a viable alternative just yet.  Subversion is
not yet stable, and at least until recently it was prohibitively slow,
but it does have the desired features.  Arch would probably work as
well, but the docs are just awful so somebody other than me would have
to evaluate it.  (Being able to have distributed trees _would_ be nice,
however!)

While looking into arch I discovered meta-cvs
(http://users.footprints.net/~kaz/mcvs.html), which is also not entirely
ready for prime time (in terms of migrating portage), but it might be
closer, and it might be _really_ nice for gentoo subprojects.  Thanks to
the work of mkennedy, we now have an mcvs ebuild, and I just added an
mcvs patch to the latest ~x86 version of viewcvs.

What makes mcvs potentially useful for us is that mcvs is essentially a
front-end to CVS which, on the server side, requires _nothing_ more than
a normal CVS repository.  The way that mcvs works, in essence, is that
when files are added to an cvs repository they are actually saved using
cryptic F-uglyhash.foo filenames along with entries in a MAP file.  This
level of indirection means that when a file is renamed, or moved, all
that really changes in the repository is the entry in the MAP file that
maps the F-uglyhash.foo file to the new location in the tree.  (Symlinks
are stored only as entries in the MAP file.)  To get a feeling for
what's going on, take a look at
http://cvs.grantgoodyear.org/viewcvs/chem332.ces.clemson.edu/?root=cvs. 
That page looks mostly like a normal cvs tree, but it's actually an mcvs
tree sitting in my cvs repository.  Viewcvs (or, to be honest, the mcvs
patch for viewcvs) doesn't handle mcvs directories as well as it might,
so instead of having actual directories (which mcvs would create upon
checkout) the directory structure is reflected in rather long filenames.
*Shrug*  If you look at the MAP file, though, you can see the mapping
between the ugly filenames and the real files.

In my opinion, the big drawbacks to meta-cvs right now are: (a) no good
tool for converting a cvs repository to mcvs without losing history and
commit comments, although it shouldn't be _that_ hard to script one, (b)
the viewcvs patch produces results that are not very pretty, (c) users,
but not cvs servers, need to install clisp to use mcvs, and (d) mcvs
needs to parse the MAP file, which could be memory intensive and lengthy
for a really large mcvs tree (such as portage), although the author of
the program notes that running CVS update on large trees takes so long
that the linear scaling to parse the MAP file may not be all that
noticeable.  

Best,
g2boojum
-- 
Grant Goodyear <g2boojum@g.o>