1 |
A recent thread discussed alternatives to CVS. As our developers know |
2 |
all too well (but some -dev readers may not), the portage tree is kept |
3 |
in CVS, which serves us reasonably well until somebody wants to move |
4 |
files around, rename files, or create symbolic links, all of which are a |
5 |
real hassle. |
6 |
|
7 |
I've been casually looking into alternatives for a while, and it's still |
8 |
not clear that there is a viable alternative just yet. Subversion is |
9 |
not yet stable, and at least until recently it was prohibitively slow, |
10 |
but it does have the desired features. Arch would probably work as |
11 |
well, but the docs are just awful so somebody other than me would have |
12 |
to evaluate it. (Being able to have distributed trees _would_ be nice, |
13 |
however!) |
14 |
|
15 |
While looking into arch I discovered meta-cvs |
16 |
(http://users.footprints.net/~kaz/mcvs.html), which is also not entirely |
17 |
ready for prime time (in terms of migrating portage), but it might be |
18 |
closer, and it might be _really_ nice for gentoo subprojects. Thanks to |
19 |
the work of mkennedy, we now have an mcvs ebuild, and I just added an |
20 |
mcvs patch to the latest ~x86 version of viewcvs. |
21 |
|
22 |
What makes mcvs potentially useful for us is that mcvs is essentially a |
23 |
front-end to CVS which, on the server side, requires _nothing_ more than |
24 |
a normal CVS repository. The way that mcvs works, in essence, is that |
25 |
when files are added to an cvs repository they are actually saved using |
26 |
cryptic F-uglyhash.foo filenames along with entries in a MAP file. This |
27 |
level of indirection means that when a file is renamed, or moved, all |
28 |
that really changes in the repository is the entry in the MAP file that |
29 |
maps the F-uglyhash.foo file to the new location in the tree. (Symlinks |
30 |
are stored only as entries in the MAP file.) To get a feeling for |
31 |
what's going on, take a look at |
32 |
http://cvs.grantgoodyear.org/viewcvs/chem332.ces.clemson.edu/?root=cvs. |
33 |
That page looks mostly like a normal cvs tree, but it's actually an mcvs |
34 |
tree sitting in my cvs repository. Viewcvs (or, to be honest, the mcvs |
35 |
patch for viewcvs) doesn't handle mcvs directories as well as it might, |
36 |
so instead of having actual directories (which mcvs would create upon |
37 |
checkout) the directory structure is reflected in rather long filenames. |
38 |
*Shrug* If you look at the MAP file, though, you can see the mapping |
39 |
between the ugly filenames and the real files. |
40 |
|
41 |
In my opinion, the big drawbacks to meta-cvs right now are: (a) no good |
42 |
tool for converting a cvs repository to mcvs without losing history and |
43 |
commit comments, although it shouldn't be _that_ hard to script one, (b) |
44 |
the viewcvs patch produces results that are not very pretty, (c) users, |
45 |
but not cvs servers, need to install clisp to use mcvs, and (d) mcvs |
46 |
needs to parse the MAP file, which could be memory intensive and lengthy |
47 |
for a really large mcvs tree (such as portage), although the author of |
48 |
the program notes that running CVS update on large trees takes so long |
49 |
that the linear scaling to parse the MAP file may not be all that |
50 |
noticeable. |
51 |
|
52 |
Best, |
53 |
g2boojum |
54 |
-- |
55 |
Grant Goodyear <g2boojum@g.o> |