The following page details the Subversion (svn) installation at Codehaus. In addition, it also provides a set of "how-to" documents for both users and administrators of Subversion repositories tailored for the haus installation. If you are not interested in the details of the Codehaus installation, skip ahead to the "how-to" documents at the end of this document (these "how-to" docs are also linked into the HowTo page).
Codehaus is running the latest and greatest version of Subversion on
beaver.codehaus.org. We're happy to say that we've been using Subversion at the house ever since v0.25 was released. At the time of this writing, the most recent version of Subversion is v1.0.1. When the Subversion team releases a new version, one can expect it to be installed at Codehaus within a few days. The previous installation of Subversion on
hogshead.codehaus.org will be retired after all projects have been migrated to the new server.
The current installation is maintained by Pete Kazmier.
The most recent version of Subversion can be found in
/usr/local/subversion directory. In reality, this is a symbolic link to a directory in the form of
version is the current version of the Subversion release. This enables the maintainer to switch back and forth between new and past installations with relative ease without impacting users. All binaries are located in
/usr/local/subversion/bin, which is automatically inserted into your
PATH upon login (via
/etc/profile.d/subversion.sh). The two most frequently used commands are
svnadmin. Their use is illustrated in the "how-to" documents at the end of this document.
Subversion features several methods to access Subversion repositories. Each access method is described in the following subsections. Please note that not all of these methods are supported by the Codehaus installation at this time. Additionally,
svn.codehaus.org is now registered to facilitate our userbase.
Local filesystem access is of limited use in the Codehaus environment because users should not be working on the Codehaus machine directly. However, there may be times when accessing a local repository is necessary. All Subversion repositories are located in the
/home/projects/project/scm directory (where
project is the name of the project). Thus, to check out a repository on the local machine, one would type:
Obviously, in order to use this repository access mechanism, you must have a shell account on the Codehaus server. Note: you must specify the full pathname to the repository when using this access method.
Similar to CVS, Subversion includes a mechanism to provide remote anonymous/read-only access to repositories. The
svnserve daemon provides this functionality. This access method enables users that do not have accounts on the Codehaus server to check out the repositories and track changes in their own local working copies. In order to check out a repository using this access method, one would type:
project is the name of the project. Note: in this case, the anonymous user does not include the actual filesystem path
/home/projects on the command line. The
svnserve daemon executes as the
apache user for security reasons. Thus, it is important that all Subversion repositories permit read access for the
apache user. By default, all projects are automatically created in this manner.
The ViewCVS installation on Codehaus has been upgraded to a more recent version which supports browsing of Subversion repositories in a manner that is familiar to most CVS users. To access the repository, go to the following URL:
project is the name of the project. Again, the only requirement is that all repositoies must be permit read-write access for the
apache user (under which the ViewCVS program is executed). By default, all projects are automatically created in this manner.
Authenticated svnserve via SSH
Secure and authenticated access to the Codehaus Subversion repositories is provided via SSH (similar to the standard CVS access method used at Codehaus). By using SSH, a secure communication channel can be established to Codehaus over which passwords can be sent safely. This method enables all users with accounts on the Codehaus machine to check out repositories in a read-write manner. In order to check out a repository using this access method, one would type:
Note: in this case, you must specify the full path to the repository which includes the actual filesystem path
/home/projects. If your username on the client machine differs from your Codehaus username, you'll need to tell Subversion to invoke SSH differently; see http://svnbook.red-bean.com/html-chunk/ch05s04.html#svn-ch-5-sect-4.2.2 for details.
WebDAV access enables users to access repositories remotely via DAV which is an extension to the HTTP protocol. The Codehaus installation does not support this remote access method for a variety of reasons. This does not indicate Codehaus will never support this access method; however, for the first release of the Subversion at Codehaus, it was decided to eliminate this access method for the following reasons:
The Codehaus web server is currently running 1.x version of Apache. WebDAV and SVN DAV modules are only available for the 2.x version of the Apache web server. At this time, Pete Kazmier did not want to undertake the migration to Apache 2.x. Furthermore, the web server process owner must have read-write access to the Subversion repositories in addition to users accessing the repository with authenticated svnserve.
One of the benefits of using Apache and WebDAV to access remote repositories is that users can be authenticated with any of the typical Apache user-authentication mechanisms. However, this is problematic because the basic authentication mechanism of Apache sends passwords in cleartext (I need to verify if Digest authentication is supported by the svn client). Thus, it now becomes necessary to secure the transport of the HTTP session which leads to the next point.
In order to provide a secure transport channel for WebDAV access to the repositories, the Codehaus Apache server must implement SSL/TLS. To properly configure the Codehaus web server, a valid certificate would have to be purchased (self-signed certificates are not an option as they provide no real security).
Subversion How-To Guides