Subversion Concepts

Subversion has numerous concepts and behaviours that might not appear immediately obvious to the user.

Importing

When importing into a Subversion repository a folder, one must remember that the contents of the directory is actually being imported, not the directory itself, into the repository location specified. So consider:

SVN Repository URL: http://joomlacode.org/svn/tccprojects/
Local File system Path: C:\Documents and Settings\moffats\My Documents\Projects\projects-external\tccprojects

What is happening is that SVN will import the contents of the local file system path into the SVN repository URL. This means it is not relevant what the name of the local system path is as the folder name is ignored and only the contents copied. Unfortunately Subversion cannot import the folder and turn it into a working copy (though the feature is planned), so one must check the resource out to create the working copy. Unless a different target folder is specified, Subversion will attempt to checkout to a folder of the same name (e.g. tccprojects), so keep this in mind when importing directories.

Subversion Server Notes

Which server model?

Since Subversion offers a few models for security, here is a guide to the usage of Subversion servers for each situation.

svnserve

Similar to pserver (for CVS), svnserve is a server process typically run from inetd and uses its own built in authentication source by default. This is useful as it allows a fully independent authentication model for the SVN repository that relies on no other sources to authenticate the user. This of course is a downfall as it becomes another login to maintain. Insurrection resolves this slightly by providing an easy administration tool but in reality for a corporate environment with pre-existing user data it is unsuitable.

SVN+SSH

This method is actually a wrapper for the above with user authentication and groups actually handled by the host system's SSH server (typically PAM). In this case a user must have physical access to the repository on the server (read-write file permissions granted by user ownership or group membership) as the system spawns a svnserve instance and transfers data over the SSH link. This is useful for a limited group of people committing to the repository who would normally have access to the servers anyway. Passwords can be linked via PAM to alternate authentication sources though it is highly suggested that SSH keys are implemented to ensure that the password dialogs aren't presented excessively. This is similar to using wrappers for CVS to access and edit repositories.

Apache

Apache is the best all round solution, especially for enterprise. Whilst users can be authenticated against the local SVN files, exactly the same as svnserve, Apache's more advanced authentication methods allow for a wider selection of authentication opportunities, such as LDAP. Additionally Apache offers SSL communication to allow encrypted links and a simple web based repository viewer that allows file downloads with a conventional web browser. This server model is perhaps the best when combined with an enterprise environment. User access control to repositories can be done using the same method employed by svnserve, and authentication may also be completed using the exact same files (in addition to methods Apache supports such as LDAP).