Sublime Subversion

The Subversion team announced the release of Subversion 1.6.5 today. This is mostly a bugfix release based on the release notes.

Here are the changes between 1.6.5 and 1.6.4.

User-visible changes:

• fix mod_dav_svn directory view links to preserve peg revisions (r38201)
• do not error on Windows when ALLUSERPROFILE dir nonexistent (r38053, -5, -7)
• properly escape lock comments over ra_neon (r38101, -2)
• allow syncing copies of ‘/’ over ra_neon and ra_serf (issue #3438)
• make ‘svnlook diff’ show empty added or deleted files (r38458)
• fix building with Apache 2.4 (r36720)
• fix possible data loss on ext4 and GPFS filesystems (issue #3442)
• resolve symlinks when checking for ~/.subversion (r36023)
• don’t let svn+ssh SIGKILL ssh processes (issue #2580)
• allow PLAIN and LOGIN mechanisms with SASL in svnserve (r38205)
• fix peg revision parsing in filenames like ‘dir/@file.txt’ (issue #3416)
• fix detection of Apache <2.0.56 (r38290, -3, -4)
• don’t pretend to do tree conflict resolution (r38799, -801, -805)
• fix data corruption when syncing from svnserve to mod_dav_svn (r38686, -7)
• fix GNOME Keyring with ‘–non-interactive’ option (r38222, -3, -61, -410)
• fixed: false “File ‘…’ already exists” error during commit (issue #3119)

Developer-visible changes:

• avoid referencing uninitialized variables (r38388)
• plug a couple of error leaks (r38572)
• improve windows test output (r38616, -7, -9, -49)

Bryan O’Sullivan just posted a wonderful article summarizing the current revision control landscape. Brian does a great job of walking through the key differences between centralized (i.e. Subversion or Perforce) and distributed (i.e. Git or Mercurial) systems, not only from a technical perspective but also workflow and culture considerations.  The result is a very concise, but thorough guide to choosing a system that will best fit the requirements of your team.

Toward the end of the article Brian reminds us just how young our field is and how much more evolution there is to come.  Revision control being such a fundamental component of software development I think we all need to work toward standards or community adopted best practices that will work across products and platforms.  This will make it easier to train new developers, encourage consistency across organizations, and ease the pain of transitioning from project to project, or company to company.

When moving to SVN from VSS there are really two different aspects to consider: technical, and social.

Technically, the answers are pretty straight forward. You need to decide where the SVN repositories will be hosted, how they will be served, and how permissions will be managed. You also need to decide whether or not you want to import your existing VSS repositories, and how much of the history you want to preserve. Finally, you need a client for your users – typically TortoiseSVN and optionally a Visual Studio plug-in like AnkhSVN or VisualSVN.

The easiest ways to set up a SVN server is to use one of the pre-packaged installers like Collabnet, VisualSVN Server, or Sublime. All of these will install Subversion and do a lot of the basic configuration for you.

Here are a few resources on the technical side:

• Migrating from VSS to SVN
• Setting up SVN on Windows
• VSS Migration Tool

Now, the social side may be a little more difficult. The biggest change is that VSS works with a check-out, edit, check-in model where SVN works with a edit, merge, commit model. This takes some getting used-to by the developers but ultimately it’s a better model in my opinion. With SVN, you essentially have the entire code-base checked out by everyone, all the time. You are free to make whatever changes you want without checking anything out. Then, when you are ready to commit your changes, you merge them with the latest version in the repository, and commit everything at once.

There are a few major benefits by taking this approach. One is that there are literally no roadblocks between a developer and the work he/she needs to do. I don’t need to wait for a file to be checked in, and if I want to make large changes I don’t need to worry about getting in anybody’s way.

The other major benefit is that each commit can represent a self-contained body of work: a feature, a bug fix, a unit test that passes, etc. All files and changes related to that body of work are contained within a single commit and it’s easy to look at the repo history and see why files were modified and how modifications relate to each-other. This is much harder to do in VSS because people usually check in file by file. Or, if they do check in multiple files at a time, it is probably because somebody else needs to edit one rather than them being finished with their particular feature.

Source control is an incredibly valuable tool for software development, but most people don’t think of it that way. Managed correctly, source control is a safety net giving developers an enormous amount of freedom to experiment, tinker, and implement with the knowledge that they can always go back if necessary.

In my opinion, you can’t do source control correctly with the check-out, edit, check-in approach. At least, not with a team of any significant size. So it’s worth some short term pain in terms of developer education for long term benefits.

Eric Sink has a great set of articles on source control overall. In chapter two he discusses the differences between these two approaches.

It’s worth pointing out that SVN does support locking which lets you get close to the check-out, edit, check-in model typical of VSS. But, I’d still recommend biting the bullet and adopting the other model.

We are creeping up on the release of version 0.6 of Sublime. Version 0.6 will be the first version to support Apache-based Active Directory / LDAP authentication. This version will work seamlessly with the Collabnet Subversion Server install which includes Apache and all of the required modules. We’re in final bugfix and testing mode right now and I expect to have a release posted to the website by mid-next week.

We are still working on Active Directory authentication which doesn’t require Apache – but this is a bit further out. It may make it into Version 1.0 of the product, but probably won’t be available before then.

Subversion with AD Auth is the holy-grail for main Microsoft-based organizations.  However, the setup can be a bit tricky and there aren’t a lot of good walk-throughs out there.  This post guides you through the process of installing Subversion and configuring AD authentication on a Windows 2003 server.

This post is NOT specific to Sublime – it applies to any Subversion installation using Apache.

Getting Ready

Before we start, you’ll need to make sure you have all required software installed.  You will need Subversion 1.5 or greater and Apache installed.  I recommend downloading the Collabnet Subversion Client and Server package for windows.  Not only does it include all prerequisites for this walk-through, but the installer sets up Apache to run as a windows service for you.

Configuring Apache

Once you have Subversion and Apahce installed, you’ll need to configure Apache to work with Subversion.  However, the first step is to ensure Apache will start on its own with no configuration changes.

1. Open your Services management console
2. Locate the Apache service (Apache2.2 for example)
3. Start the service.  If there is a problem, you will get a warning or error message.

One common error on a new installation is when Apache conflicts with IIS.  If you see an error message about no listening sockets available, that probably means that IIS is already running a website on the default port 80.  You can either change Apache to run on a different port (by editing the httpd.conf file), or stop the default website in IIS.

Once you have Apache running on its own, it’s time to configure Subversion.

1. Open the httpd.conf file (mine is located at C:\Program Files\CollabNet Subversion Server\httpd\conf\httpd.conf).
2. Locate the Dynamic Shared Object (DSO) Support section.  This should have a bunch of lines that begin with “LoadModule …”
3. At the bottom of the existing LoadModule lines, add the following three lines:LoadModule ldap_module   modules/mod_ldap.so
LoadModule authnz_ldap_module   modules/mod_authnz_ldap.so
LoadModule authz_svn_module   modules/mod_authz_svn.so

4. Next locate the <Location> tag for the path where your repositories will be accessible from.  By default with the Collabnet install this will be /svn.  In that case you would look for <Location /svn>.  If you configured a different path, just substitute /svn for the path you configured.  It should look something like this: <Location /svn>
DAV svn
SVNParentPath C:/svn_repository
</Location>

   The SVNParentPath should be the full path to the directory where you will store your repositories.  In this case, all repositories will be located at C:\svn_repository\<my_repo>.

5. Add the following settings to this Location tag:SVNListParentPath On
   Set this to On if you are hosting multiple repositories and want Apache to display a list of repositories.

   AuthzSVNAccessFile C:/svn_repository/access.txt
   This is the full path to the file which will control access (we’ll create that next)

   AuthzLDAPAuthoritative off
   If on, this prevents another auth provider from handling authentication if ldap authentication fails.

   AuthType Basic
   Specifies basic auth.  You can change this to Digest or a different auth type if you like.

   AuthBasicProvider ldap
   Specifies that the LDAP provider will be used for authentication.

   AuthName "your.domain"
   This specifies the realm for authentication.  For simplicity, just set this to the fully qualified name of your domain.

   AuthLDAPBindDN "CN=SomeAccount,CN=Users,DC=your,DC=domain"
   This needs to be the fully qualified account name of an account that has read access to your domain.

   AuthLDAPBindPassword "password"
   This should be the password for the account specified in AuthLDAPBindDN.

   AuthLDAPURL "ldap://your.domain/DC=your,DC=domain?sAMAccountName?sub?(objectClass=*)"
   This will be used to locate users in your domain.  Everything to the left of the first question mark should be the ldap path where your users are located.  To the right of the first question mark is the user property that will be used as the username.  Typically you will use “sAMAccountName”, but if you wanted to have users use their email address as their username, you could use “mail” instead.  Leave the rest of the path unchanged.

   Require valid-user
   Specifies that a valid user account is required.

6. Once you are done, the entire <Location / svn> section should look like this:<Location /svn>
DAV svn
SVNParentPath C:/svn_repository
SVNListParentPath On
AuthzSVNAccessFile C:/svn_repository/access.txt
AuthzLDAPAuthoritative off
AuthType Basic
AuthBasicProvider ldap
AuthName "your.domain"
AuthLDAPBindDN "CN=account,CN=Users,DC=your,DC=domain"
AuthLDAPBindPassword "password"
AuthLDAPURL "ldap://your.domain/DC=your,DC=domain?sAMAccountName?sub?(objectClass=*)"
Require valid-user
</Location>

7. Next, restart the Apache service in your Services management console.  If you get an error, check the event log and double check the settings above.  If you don’t receive any errors, move on to the next section.

Setting up Access

The final step is to set up access for your repositories. Create a new file called “access.txt” where your repositories are located. This file should be at the same path you specified for the AuthzSVNAccessFile setting in the httpd.conf file. It doesn’t have to be where your repositories are located, it can be anywhere.

For each repository, create an entry like the following:

[myrepo:/]
user1 = rw
user2 = rw
user3 = r


I won’t go into the format of this file because you can find extensive documentation in the Subversion Book. However, the important thing to understand is that the username you use will be based on property specified in the AuthLDAPURL setting in your httpd.conf. For example, if you specified sAMAccountName, you will enter the account name (without the domain portion). If you specified mail, you would enter the email address.

Save the access.txt file.

That’s it. You can now try checking out a repository by running the following command:

svn co http://localhost/svn/myrepo