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

[Ryan Phillips]

* Grant Goodyear <g2boojum@g.o> [2004-01-27 12:30]:
> 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.
>

I have some experience with ARCH/TLA but only on small projects.  It
is very nice in terms of distributed repositories, and the
documentation isn't all that bad. There is a wiki
(http://wiki.sourcecontrol.net/moin.cgi/) that has a whole bunch of
information.

What is is nice about arch is the branches.  In arch you can actually
keep track of different branches easily and painlessly.  Say we want a
stable, unstable, cutting-edge branch for the portage tree.  It is
possible to merge specific patches from one branch into another for
say security fixes, and maintainability.  Say KDE from the unstable
branch becomes stable, just merge the patch-set for kde over to the
stable branch.

In addition, CVS and ARCH can be used together for a 'trial run'.
There is a guide here
(http://wiki.sourcecontrol.net/moin.cgi/Arch_20and_20CVS_20in_20the_20same_20tree)
to help you.  Using arch and CVS together shouldn't mess up anything,
the arch directories are not committed to the CVS.

Regards,
Ryan