| 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 |
Archives