1 |
On Thu, 2004-04-29 at 07:07, Eric Sammer wrote: |
2 |
|
3 |
> This is certainly a quick way to get some of the functionality of a |
4 |
> frozen tree, but it does not capture the other needs such as longevity |
5 |
> of branches, etc. See this list's archives for a detailed (and extremely |
6 |
> interesting) debate about this as Andrew said. |
7 |
|
8 |
Well, the "obvious" solution is: |
9 |
|
10 |
1) Use CVS branches. |
11 |
|
12 |
2) Update your portage tree with CVS instead of rsync. |
13 |
|
14 |
The problem with the obvious solution is speed. One of the previously |
15 |
discussed solutions is CVSUp: |
16 |
|
17 |
http://www.gentoo.org/news/en/gwn/20021223-newsletter.xml#doc_chap2_sect4 |
18 |
http://www.gentoo.org/doc/en/cvsup.xml |
19 |
|
20 |
1.5 years later, we seem to be no closer to doing this, and this may |
21 |
well be due to Modula 3 support. |
22 |
|
23 |
A variation on the obvious answer is to use Subversion instead of CVS. |
24 |
The existing repository could be imported (I've done this with |
25 |
http://cvs2svn.tigris.org/ on a relatively small repository), and there |
26 |
are tools to mirror the repository (SVN::Mirror perl module). |
27 |
|
28 |
Then, as an end user, you either check out the trunk, if you want all |
29 |
the bleeding edge stuff, or you check out one of the branches, if you |
30 |
want stability. Subversion works pretty much like CVS from the command |
31 |
line, so it would look something like this: |
32 |
|
33 |
svn co http://svn.gentoo.org/portage/trunk /usr/portage # or |
34 |
svn co http://svn.gentoo.org/portage/branches/2004.1 /usr/portage |
35 |
svn update /usr/portage # done by emerge sync |
36 |
|
37 |
There are actually Python bindings for Subversion, so portage might use |
38 |
those directly (except they require swig). URLs assume apache2 + |
39 |
mod_dav_svn, but there is also a stand-alone svnserver (like CVS |
40 |
pserver), in which case you change the protocol from http to svn. |
41 |
|
42 |
One nice Subversion feature that directly benefits the portage tree is |
43 |
that you can rename and copy files and it still tracks their lineage. |
44 |
For example, seems like every quarter or so we get a new package |
45 |
category, like when app-games exploded into games-*. When something like |
46 |
this happens, you just need to do a svn mv oldfile newfile. As an |
47 |
additional benefit, this does not actually duplicate the file inside the |
48 |
repository; it's more like if you did a mv in the filesystem. The docs |
49 |
refer to this as a "cheap copy". Another more common operation is that |
50 |
most ebuild version bumps simply amount to copying the ebuild to new |
51 |
name and updating the CVS $Header$. Rather than doing cp oldfile newfile |
52 |
&& cvs add newfile, you can do svn cp oldfile newfile and get a cheap |
53 |
copy. |
54 |
|
55 |
http://svnbook.red-bean.com/svnbook/ch04s02.html |
56 |
|
57 |
Also, I believe the keyword substitution (i.e. $Header$) only happens in |
58 |
the local working copy, and expanded keywords are not stored in the |
59 |
repository, which further saves space. |
60 |
|
61 |
http://svnbook.red-bean.com/svnbook/ch07s02.html |
62 |
|
63 |
Additional caveats/notes about Subversion: |
64 |
|
65 |
Although Subversion is past the 1.0 release, it's still relatively new |
66 |
code, and it does not yet have the user experience that CVS enjoys. |
67 |
However, the Subversion people do eat their own dog food (their own |
68 |
repository runs on Subversion), and the command line interface is very, |
69 |
very close to CVS's. |
70 |
|
71 |
Subversion uses the Apache Portable Runtime Library. Leveraging existing |
72 |
code is generally a good thing, particularly if it's from something as |
73 |
widely-deployed as Apache, and the Subversion tarballs have APR in them |
74 |
already (in fact, the package blocks dev-libs/apr). |
75 |
|
76 |
The server stores the repository in a Berkeley DB4 database (not needed |
77 |
for clients). |
78 |
|
79 |
Clients and servers need net-misc/neon (WebDAV client library). |
80 |
|
81 |
None of the dependencies look like they would be an issue for a |
82 |
bootstrap client, and you might not need subversion for a bootstrap |
83 |
client anyway, if you get a copy of the portage tree as a tarball. |
84 |
|
85 |
Subversion clients ought to be usable on any platform that support |
86 |
Apache (x86, ppc, alpha, hppa, mips, sparc, amd64, ia64) and neon (x86, |
87 |
ppc, sparc, amd64, but other platforms may just not be tested yet), and |
88 |
servers on any platform that supports db4 (looks like everything). |
89 |
-- |
90 |
Andy Dustman <adustman@×××××××××.edu> |
91 |
Office of Information Technology, Terry College of Business, UGA |