Start Subversion at Boot on Ubuntu

I don’t know if I’ve extolled the virtues of Ubuntu on this blog yet, but they are many. They are, however, not the topic of this post. Every once in a while, I like to try different operating systems on my server, and at the moment, I’m just coming back to an Ubuntu server after a brief fling with Windows Server 2003.

On the list of things to do after install was to get Ubuntu to start the svnserve daemon at boot. I’ve taken the time to look this up enough times that I figured I’d just add it here. This procedure holds for anything you’d like to do at boot, I’m simply running my svn daemon.

Step 1 – Create your script.
Simply create a new file (I called mine svnserve) and type the command you’d like to run

cd /etc/init.d/ # (thanks Alfonso)
sudo touch svnserve
sudo vi svnserve
svnserve -d -r /usr/local/svn/repository_name

Step 2 – Save the script in the /etc/init.d/ folder

Step 3 – Make the script executable
sudo chmod +x svnserve

Step 4 – Add the script to the boot sequence
sudo update-rc.d svnserve defaults

That’s it. When you’re done you should see some output similar to

Adding system startup for /etc/init.d/svnserve ...
/etc/rc0.d/K20svnserve -> ../init.d/svnserve
/etc/rc1.d/K20svnserve -> ../init.d/svnserve
/etc/rc6.d/K20svnserve -> ../init.d/svnserve
/etc/rc2.d/S20svnserve -> ../init.d/svnserve
/etc/rc3.d/S20svnserve -> ../init.d/svnserve
/etc/rc4.d/S20svnserve -> ../init.d/svnserve
/etc/rc5.d/S20svnserve -> ../init.d/svnserve

Install SVN Server in Ubuntu Server


Subversion is an open source version control system. Using Subversion, you can record the history of source files and documents. It manages files and directories over time. A tree of files is placed into a central repository. The repository is much like an ordinary file server, except that it remembers every change ever made to files and directories.


To access Subversion repository using the HTTP protocol, you must install and configure a web server. Apache2 is proven to work with Subversion. Please refer to the HTTP subsection in the Apache2 section to install and configure Apache2. To access the Subversion repository using the HTTPS protocol, you must install and configure a digital certificate in your Apache 2 web server. Please refer to the HTTPS subsection in the Apache2 section to install and configure the digital certificate.

To install Subversion, run the following command from a terminal prompt:

sudo apt-get install subversion libapache2-svn

Server Configuration

This step assumes you have installed above mentioned packages on your system. This section explains how to create a Subversion repository and access the project.

Create Subversion Repository

The Subversion repository can be created using the following command from a terminal prompt:

svnadmin create /path/to/repos/project

Importing Files

Once you create the repository you can import files into the repository. To import a directory, enter the following from a terminal prompt:

svn import /path/to/import/directory file:///path/to/repos/project

Access Methods

Subversion repositories can be accessed (checked out) through many different methods –on local disk, or through various network protocols. A repository location, however, is always a URL. The table describes how different URL schemes map to the available access methods.

Table 14.1. Access Methods

Schema Access Method
file:// direct repository access (on local disk)
http:// Access via WebDAV protocol to Subversion-aware Apache2 web server
https:// Same as http://, but with SSL encryption
svn:// Access via custom protocol to an svnserve server
svn+ssh:// Same as svn://, but through an SSH tunnel

In this section, we will see how to configure Subversion for all these access methods. Here, we cover the basics. For more advanced usage details, refer to the svn book.

Direct repository access (file://)

This is the simplest of all access methods. It does not require any Subversion server process to be running. This access method is used to access Subversion from the same machine. The syntax of the command, entered at a terminal prompt, is as follows:

svn co file:///path/to/repos/project


svn co file://localhost/path/to/repos/project
If you do not specify the hostname, there are three forward slashes (///) — two for the protocol (file, in this case) plus the leading slash in the path. If you specify the hostname, you must use two forward slashes (//).

The repository permissions depend on filesystem permissions. If the user has read/write permission, he can checkout from and commit to the repository.

Access via WebDAV protocol (http://)

To access the Subversion repository via WebDAV protocol, you must configure your Apache 2 web server. You must add the following snippet in your /etc/apache2/apache2.conf file:

 <Location /svn>
  DAV svn
  SVNPath /path/to/repos
  AuthType Basic
  AuthName "Your repository name"
  AuthUserFile /etc/subversion/passwd
  Require valid-user

To import or commit files to your Subversion repository over HTTP, the repository should be owned by the HTTP user. In Ubuntu systems, normally the HTTP user is www-data. To change the ownership of the repository files enter the following command from terminal prompt:

sudo chown -R www-data:www-data /path/to/repos
By changing the ownership of repository as www-data you will not be able to import or commit files into the repository by running svn import file:/// command as any user other than www-data.

Next, you must create the /etc/subversion/passwd file. This file contains user authentication details. To add an entry, i.e. to add a user, you can run the following command from a terminal prompt:

sudo htpasswd -c /etc/subversion/passwd user_name

This command will prompt you to enter the password. Once you enter the password, the user is added. Now, to access the repository you can run the following command:

                      svn co http://servername/svn
The password is transmitted as plain text. If you are worried about password snooping, you are advised to use SSL encryption. For details, please refer next section.

Access via WebDAV protocol with SSL encryption (https://)

Accessing Subversion repository via WebDAV protocol with SSL encryption (https://) is similar to http:// except that you must install and configure the digital certificate in your Apache2 web server.

You can install a digital certificate issued by a signing authority like Verisign. Alternatively, you can install your own self-signed certificate.

This step assumes you have installed and configured a digital certificate in your Apache 2 web server. Now, to access the Subversion repository, please refer to the above section! The access methods are exactly the same, except the protocol. You must use https:// to access the Subversion repository.

Access via custom protocol (svn://)

Once the Subversion repository is created, you can configure the access control. You can edit the /path/to/repos/project/conf/svnserve.conf file to configure the access control. For example, to set up authentication, you can uncomment the following lines in the configuration file:

# [general]
# password-db = passwd

After uncommenting the above lines, you can maintain the user list in the passwd file. So, edit the file passwd in the same directory and add the new user. The syntax is as follows:

username = password

For more details, please refer to the file.

Now, to access Subversion via the svn:// custom protocol, either from the same machine or a different machine, you can run svnserver using svnserve command. The syntax is as follows:

$ svnserve -d --foreground -r /path/to/repos
# -d -- daemon mode
# --foreground -- run in foreground (useful for debugging)
# -r -- root of directory to serve

For more usage details, please refer to:
$ svnserve --help

Once you run this command, Subversion starts listening on default port (3690). To access the project repository, you must run the following command from a terminal prompt:

svn co svn://hostname/project project --username user_name

Based on server configuration, it prompts for password. Once you are authenticated, it checks out the code from Subversion repository. To synchronize the project repository with the local copy, you can run the update sub-command. The syntax of the command, entered at a terminal prompt, is as follows:

cd project_dir ; svn update

For more details about using each Subversion sub-command, you can refer to the manual. For example, to learn more about the co (checkout) command, please run the following command from a terminal prompt:

                      svn co help

Access via custom protocol with SSL encryption (svn+ssh://)

The configuration and server process is same as in the svn:// method. For details, please refer to the above section. This step assumes you have followed the above step and started the Subversion server using svnserve command.

It is also assumed that the ssh server is running on that machine and that it is allowing incoming connections. To confirm, please try to login to that machine using ssh. If you can login, everything is perfect. If you cannot login, please address it before continuing further.

The svn+ssh:// protocol is used to access the Subversion repository using SSL encryption. The data transfer is encrypted using this method. To access the project repository (for example with a checkout), you must use the following command syntax:

svn co svn+ssh://hostname/var/svn/repos/project
You must use the full path (/path/to/repos/project) to access the Subversion repository using this access method.

Based on server configuration, it prompts for password. You must enter the password you use to login via ssh. Once you are authenticated, it checks out the code from the Subversion repository.

Configuring Subversion with Active Directory Authentication

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/
    LoadModule authnz_ldap_module   modules/
    LoadModule authz_svn_module   modules/
  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
    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
  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:

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

Referenced by:

Setting up Subversion on Windows

When it comes to readily available, free source control, I don’t think you can do better than Subversion at the moment. I’m not necessarily advocating Subversion; there are plenty of other great source control systems out there — but few can match the ubiquity and relative simplicity of Subversion. Beyond that, source control is source control, as long as you’re not using Visual SourceSafe. And did I mention that Subversion is … free?

Allow me to illustrate how straightforward it is to get a small Subversion server and client going on Windows. It’ll take all of 30 minutes, tops, I promise. And that’s assuming you read slowly.

The first thing we’ll do is download the latest Subversion Windows binary installer. At the time of writing, that’s 1.46. I recommend overriding the default install path and going with something shorter:


Note that the installer adds c:\svn\bin to your path, so you can launch a command prompt and start working with it immediately. Let’s create our first source repository, which is effectively a system path.

svnadmin create "c:\svn\repository"

Within that newly created folder, uncomment the following lines in the conf/svnserve.conf file by removing the pound character from the start of each line:

anon-access = none
auth-access = write
password-db = passwd

Next, add some users to the conf/passwd file. You can uncomment the default harry and sally users to play with, or add your own:

harry = harryssecret
sally = sallyssecret

As of Subversion 1.4, you can easily install Subversion as a Windows service, so it’s always available. Just issue the following command:

sc create svnserver binpath= "c:\svn\bin\svnserve.exe --service -r c:\svn\repository"
displayname= "Subversion" depend= Tcpip start= auto

It’s set to auto-start so it will start up automatically when the server is rebooted, but it’s not running yet. Let’s fix that:

net start svnserver

Note that the service is running under the Local System account. Normally, this is OK, but if you plan to implement any Subversion hook scripts later, you may want to switch the service identity to an Administrator account with more permissions. This is easy enough to do through the traditional Windows services GUI.

Subversion service screenshot

Now let’s verify that things are working locally by adding a root-level folder in source control for our new project, aptly named myproject.

set SVN_EDITOR=c:\windows\system32\notepad.exe
svn mkdir svn://localhost/myproject

It’s a little weird when running locally on the server, as Subversion will pop up a copy of Notepad with a place for us to enter commit comments. Every good programmer always comments their source control actions, right?

Subversion local commit, notepad comment

Enter whatever comment you like, then save and close Notepad. You’ll be prompted for credentials at this point; ignore the prompt for Administrator credentials and press enter. Use the credentials you set up earlier in the conf/passwd file. If everything goes to plan, you should be rewarded with a “committed revision 1” message.

svn mkdir svn://localhost/myproject
Authentication realm: <svn://localhost:3690>
Password for 'Administrator': [enter]
Authentication realm: <svn://localhost:3690>
Username: sally
Password for 'sally': ************

Committed revision 1.

Congratulations! You just checked your first change into source control!

We specified svn:// as the prefix to our source control path, which means we’re using the native Subversion protocol. The Subversion protocol operates on TCP port 3690, so be sure to poke an appropriate hole in your server’s firewall, otherwise clients won’t be able to connect.

Now that the server’s good to go, let’s turn our attention to the client. Most people use TortoiseSVN to interact with Subversion. Download the latest 32-bit or 64-bit Windows client ( as of this writing) and install it. The installer will tell you to reboot, but you don’t have to.

Now create a project folder somewhere on your drive. I used c:\myproject. Tortoise isn’t a program so much as a shell extension. To interact with it, you right click in Explorer. Once you’ve created the project folder, right click in it and select “SVN Checkout…”

Tortoise 'SVN Checkout...'

Type svn://servername/myproject/ for the repository URL and click OK.

Tortoise checkout dialog

Tortoise now associates the c:\myproject folder with the svn://servername/myproject path in source control. Anything you do on your local filesystem path (well, most things– there are some edge conditions that can get weird) can be checked back in to source control.

There’s a standard convention in Subversion to start with the “TTB folders” at the root of any project:

Because Subversion uses regular directory copies for branching and tagging (see Chapter 4, Branching and Merging), the Subversion community recommends that you choose a repository location for each project root — the “top-most” directory which contains data related to that project — and then create three subdirectories beneath that root: trunk, meaning the directory under which the main project development occurs; branches, which is a directory in which to create various named branches of the main development line; tags, which is a collection of tree snapshots that are created, and perhaps destroyed, but never changed.

Of course, none of this means your developers will actually understand branching and merging, but as responsible Subversion users, let’s dutifully add the TTB folders to our project. Note that we can batch up as many changes as we want and check them all in atomically as one unit. Once we’re done, right click the folder and select “SVN Commit…”

Tortoise 'SVN Commit...'

In the commit dialog, indicate that yes, we do want to check in these files, and we always enter a checkin comment– right? right?

Tortoise Commit dialog

You’ll have to enter your server credentials here, but Tortoise will offer to conveniently cache them for you. Once the commit completes, note that the files show up in the shell with source control icon overlays:

Tortoise folder with source control icon overlays

And now we’re done. Well, almost. There are a few settings in Tortoise you need to pay special attention to. Right click and select “TortoiseSVN, Settings”.

  1. See that hidden “.svn” folder? These folders are where Subversion puts its hidden metadata schmutz so it can keep track of what you’re doing in the local filesystem and resolve those changes with the server. The default naming convention of these folders unfortunately conflicts with some fundamental ASP.NET assumptions. If you’re an ASP.NET 1.x developer, you need to switch the hidden folders from “.svn” to “_svn” format, which is on the General options page. This hack is no longer necessary in ASP.NET 2.0 or newer.
  2. I’ll never understand why, but by default, Tortoise tries to apply source control overlays across every single folder and drive on your system. This can lead to some odd, frustrating file locking problems. Much better to let Tortoise know that it should only work its shell magic on specific folders. Set this via “Icon Overlays”; look for the exclude and include paths. I set the exclude path to everything, and the include path to only my project folder(s).tortoise exclude and include paths

Unfortunately, since Tortoise is a shell extension, setting changes may mean you need to reboot. You can try terminating and restarting explorer.exe, but I’ve had mixed results with that.

And with that, we’re done. You’ve successfully set up a Subversion server and client. A modern client-server source control system inside 30 minutes — not bad at all. As usual, this is only intended as the gentlest of introductions; I encourage you to check out the excellent Subversion documentation for more depth.

I find Subversion to be an excellent, modern source control system. Any minor deficiencies it has (and there are a few, to be clear) are more than made up by its ubiquity, relative simplicity, and robust community support. In the interests of equal time, however, I should mention that some influential developers — most notably Linus Torvaldshate Subversion and view it as an actual evil. There’s an emerging class of distributed revision control that could eventually supercede existing all the centralized source control systems like Subversion, Vault, Team System, and Perforce.

I’m skeptical. I’ve met precious few developers that really understood the versioning concepts in the simple centralized source control model. I have only the vaguest of hopes that these developers will be able to wrap their brains around the vastly more complicated and powerful model of distributed source control. It took fifteen years for centralized source control usage to become mainstream, so a little patience is always advisable.

Referenced by: