I first took a look at Subversion 15 days ago. It's similarity to CVS made me want to dig deeper.

Here's what I found out during the past two weeks.

Building from Source

Building Subversion source from trunk on Fedora Core 1 is straight forward. I ran autogen.sh to create the ./configure script. Running ./configure revealed that I don't have the right version of apr (Apache Portable Runtime, part of Apache HTTP Server 2.0). FC1 ships 0.9.4 but 0.9.5 or 1.0 is required. Similarly for apr-util. The INSTALL file mentions that I need the WebDAV/DeltaV library neon version 0.24.4, FC1 ships with 0.24.3.

So I went to their respective web sites and grabbed the sources from CVS. Neon 0.24.4 requires autoconf 2.58, but FC1 has only 2.57. Luckily Subversion trunk will build with neon 0.24.3 and the chase stopped there.

The build itself is uneventful. First apr, then apr-util and finally svn, informing each step the location of the result of the previous steps with the --with-apr=/opt/apr and --with-apr-util=/opt/apr-util switches to ./configure. The result is here:

[root@gao svn]# pwd
/opt/svn
[root@gao svn]# ls
bin  include  info  lib  man  share
[root@gao svn]# ls bin
svn  svnadmin  svndumpfilter  svnlook  svnserve  svnversion
[root@gao svn]# ls lib
libsvn_client-1.a         libsvn_ra-1.a               libsvn_repos-1.a
libsvn_client-1.la        libsvn_ra-1.la              libsvn_repos-1.la
libsvn_client-1.so        libsvn_ra-1.so              libsvn_repos-1.so
libsvn_client-1.so.0      libsvn_ra-1.so.0            libsvn_repos-1.so.0
...

The build process also created the Apache modules mod_dav_svn.so and mod_authz_svn.so and placed them in /usr/lib/httpd/modules. The httpd.conf is modified to add lines that load and configure the modules. Unfortunately this also broke Apache, making is unstartable, claiming that it cannot find certain symbol. I backed out my build and sticked with version 0.32.1 that came with FC1 for the rest of the test.

The official Fedora Core 1 build of Subversion 1.0 should arrive any day now.

The Book

The book Version Control with Subversion, by Ben Collins-Sussman, Brian W. Fitzpatrick, and C. Michael Pilato, a soon to be published O'Reilly book covering Subversion, is available from the same place where the CVS book is available.

This is an absolutely fantastic book to read. This is the kind of book that even though it is available for free over the Internet, you still want to buy a paper copy. Here's the Amazon.com pre-order link.

It is written in a very engaging expository style. It explains the theory behind Subversion carefully, clearly, and thoroughly. It gives examples that can actually be carried out on the computer.

Creating a Repository

Creating a Subversion repository is done using the svnadmin program.

[weiqi@gao] $ svnadmin create svnroot
[weiqi@gao] $ cd svnroot
[weiqi@gao] $ ls
dav  db  format  hooks  locks  README.txt
[weiqi@gao] $ ls db
changes   __db.002  __db.005        nodes            strings
copies    __db.003  DB_CONFIG       representations  transactions
__db.001  __db.004  log.0000000001  revisions        uuids

Setting Up mod_dav_svn

FC1's Apache 2.0 installation contains a /etc/httpd/conf/httpd.conf that will include any configuration file from the /etc/httpd/conf.d directory. The subversion.conf file contain everything I need to configure a Subversion repository to be accessible from the network. All I have to do is to uncomment some lines and plug in my own repository location.

LoadModule dav_svn_module     modules/mod_dav_svn.so
LoadModule authz_svn_module   modules/mod_authz_svn.so
 
<Location /svn>
   DAV svn
   SVNPath /var/svnroot
</Location>

After restarting Apache, I can point my browser to the URL http://localhost/svn and browse the latest revision of the repository. However to perform any meaningful action, I still need my Subversion client.

Add Content To Repository

Import is simpler with Subversion, compared to CVS.

[weiqi@gao] $ svn import foo http://localhost/svn/foo

Just for fun, I imported the Linux kernel source into my Subversion repository. Here's some interesting statistics:

• Before import, the kernel source tree directory has a du -s size of 207452. After import, it's 506092.
• Before import, the empty repository has a size of 1024. After import, the size become 493472.
• The import took 22 minutes on my machine.
• Checking it out to a different location took about the same amount of time.

The reason that the directory size is doubled is because Subversion creates a .svn subdirectory in each directory of the tree, and save a pristine copy of every file in the directory there. This allows Subversion to do several things without talking to the repository. It also allows Subversion to send only diffs when committing, which is not the case for CVS.

CVS Replacement

Is Subversion a good CVS replacement? Sure. It can do everything that CVS can do and do them better. Everything you've heard about how Subversion is a better CVS is true: versioned directories, atomic commits, easier branching and tagging (they are cheap copies), file and directory metadata (properties), not breaking binary files, nicer status outputs, safer updates/merges, etc.

We should convince Dave Thomas and Andy Hunt to write a version of their Pragmatic Version Control for Subversion.

Caveats

As much as I like Subversion, there are several things that I failed to do. I can't seem to build the Java bindings of the Subversion Client API (a SWIG based JNI deal). I can't seem to get the IDEA plugin (svnup) to work. The Emacs integration provided by vc-svn.el (a VC backend written by Jim Blandy) seems to work, but is lacking in some areas (e.g., I can't rename a file using it, probably because it VC still trying to do it the CVS way). Conflict resolution still is a manual process. Mature GUI frontends for Subversion seems still some time away.

Responses[3]

Posted by Weiqi Gao on March 15, 2004 12:06:13 AM CST #