John Zablocki's dllHell.net

The CollabNet binaries for Subversion generally provide a simple means for setting up Subversion on a Windows box. The build includes Apache and the installer will get you up and running rather quickly. In the years since I’ve started using Subversion, I’ve always used Apache and therefore http as the svn protocol. Recently, I decided to avoid the extra steps involved with setting up Apache and SVN and opted instead for running the svnserve.exe as a Windows service. I’ve run into a few gotchas that I think are worth noting.

Subversion’s basic security simply stores plain text passwords. If you’re looking for a better means to protect user information, you need to use SASL. SASL allows you to create a binary users file, without plaintext passwords. SASL uses a config file, svn.conf that you store in a known path (where the SASL binaries live).

I first got svnserve.exe up and running by running it from the command line:

svnserve.exe -d -r c:\path\to\repos

Everything was working fine. So I decided to install svnserve as a Windows service. The strange thing is the CollabNet installer prompts to install the service into SCM. But even when checked, it didn’t. I tried to run the installer again to fix, upgrading from 1.4 to 1.5. The 1.5 installer changed the install path from C:\Program Files\CollabNet Subversion Server to C:\Program Files\CollabNet\Subversion Server (note the extra slash). I failed to notice this change and had parallel installations.

I googled around and found that svnserve.exe actually needs to be installed with sc (unclear on the MSI’s checkbox). So I ran:

sc create svnserve binPath="C:\Program Files..."

After some hair pulling and hand wringing, I realized that the options for sc require a space after the equals sign. There’s a vague help entry about it when you run sc, but it’s odd and subtle and will drive you crazy. The space in the Program Files path also requires some escaped quotes:

binPath="\"C:\Program Files\CollabNet Subversion Server\svnserve.exe\" --service -r: c:\repos"

Once I finally got the service installed, I was getting errors trying to start the service. I had inadvertently continued to use the old installed path “CollabNet Subversion Server” vs. “CollabNet\Subversion Server.” After I got the service running against the correct path, I started to get SASL errors.

I kept getting invalid user not found errors, though I clearly had a password file that was valid. There’s a SASL utility for checking the user list in the files. As an experiment, I stopped the service and ran the command line. It worked. I checked my SASL conf file.

pwcheck_method: auxprop
auxprop_plugin: sasldb
sasldb_path: passwordsdb.txt
mech_list: DIGEST-MD5

It then occurred to me, that when svnserve.exe is running as a service, it wasn’t resolving sasldb_path to the correct path. I find this behavior odd, because I ran the command line from my users directory and not the CollabNet\Subversion Server directory. After that, everything was working as expected.

My first experience with version control was VSS. I used it exclusively for SCM tasks until about three years ago when I started teaching at Fairfield U. I learned enough to teach the basics (through Subclipse) to college students who had never even coded before. Eventually, I was lured in further by its better checkout model and the oh-so-shiny TortoiseSVN. I signed up for an account at CVSDude and started hosting my personal projects there (great service). I’ve also migrated three companies with substantial codebases from VSS or SourceGear to Subversion. Along the way, I’ve wrestled with the various ways of structuring a repository. This post will describe what I’ve found to be useful…

There are lots of examples on how to layout your repository. Google around and you’ll find plenty of ideas. What I’ve not found in abundance is how to structure a typical repository within a corporate codebase. If you have only one product, it’s simple. But what about the more common case where a business has several related applications, with a few shared libraries. In this setting, there will be multiple web apps, services, console apps and scripts. But it all goes to support a single product.

For this example, I’ve tried (and seen many others try) the approach where each application has its own development branch. For example:

MyCommonLibrary/trunk
MyWebApplication/trunk
MyOtherWebApplication/trunk

One big problem with this approach is that branches that cut across applications are hard to manage. One logical branch has many physical branches. While there may be other limitations (excessive use of externals for dependencies) with this structure, this one was enough for me to move to a single branch tree. A single development trunk poses some challenges. The structure below is one I typically use and is the result of studying projects such as Spring.NET

trunk/
       /build
       /docs
       /lib
             /thirdparty
             /legacy
       /db
            /migrations
            /dml
            /ddl
       /src
            /components
            /tests
            /webs
            /tasks
            /services

The structure should be pretty self explanitory, but I’ll describe it briefly.

• build – NAnt or MSBuild common files.
• docs – Help files and the like. Stuff that’s not project documentation.
• lib – Common assemblies. All project references are to assemblies in this structure
• db – Database migrations and any non-migration DDL or DML.
• src – All applications. Common libraries are in components.

While this structure won’t work for everyone, I’ve found it to be a good starting point. It provides some obvious benefits over the alternate structure I described above.

1. Keeping dependencies in source control means all working copies should be buildable. No assumed install paths or GAC requirements.
2. Project references are easy to manage. All common libraries are in one path. Relative references may be used.
3. Organizing the repository by app type (web, task, etc.) allows for solution files to be created by type (e.g., Webs.sln, Tasks.sln)
4. It’s easy to structure a Master.sln file at the root of src that includes the entire tree. This solution file is important for having a single buildable solution for CruiseControl.NET
5. Branching is easy for cross-cutting changes. This attribute means it’s also easy to setup a build in CC.NET for a branch, since all is relative.