Category Archives: Control Version

Quick and easy setup of Mercurial server on Windows

by Gilles QUERRET

Installing Mercurial on a Linux server is a matter of minutes (depending on your Linux distro). But I had to install it on a Windows server, and there are subtle pitfalls you’re likely to encounter when doing that. This post is by no mean a full and detailed installation process for every configuration, it will just focus on a simple install.

Step 1 : HTTPD install
HTTPD is one of the widely used HTTP server. The Windows version can be downloaded fromhere. I’m using the 2.2.17 Win32 Binary including OpenSSL 0.9.8o. Choosing a typical install will use C:\Program Files (x86)\Apache Software Foundation\Apache2.2 as the default directory. The only specific step during install is this screen :

Just fill with appropriate values depending on your network.

Step 2 : Python install
Python is needed by Mercurial. You always have to use the same Python version as the one used by Mercurial. The current Mercurial version (1.7.5) is still using 2.6, so download this version from Python website. Even if you’re running Win x64, download the x86 version as I encountered some bugs with the 64 bits package (no idea why). Use the default settings for everything (especially installation directory).

Step 3 : Mercurial install
Mercurial compiled for Windows can be downloaded from here. Never use TortoiseHg to setup a Mercurial server, it won’t work correctly (and easily). Always download *.win32-py2.6.exe packages, they’re easier to setup.
Setup should detect your Python version and so compile Mercurial with Python 2.6.

Step 4 : Create directory structure
This test installation will use 3 differents directories to host repositories. We will use subfolders of C:\Repositories , named /Production, /QA and /Dev
We will keep them empty for now, just create this structure.

Step 5 : HTTPD setup
Create a new file called hgweb.cgi in C:\Program Files (x86)\Apache Software Foundation\Apache2.2\cgi-bin with this content :

#!C:/Python26/python.exe -u

# See also
# Path to repo or hgweb config to serve (see ‘hg help hgweb’)
config = “C:/Program Files (x86)/Apache Software Foundation/Apache2.2/cgi-bin/hgweb.config”

# Uncomment and adjust if Mercurial is not installed system-wide:
# import sys; sys.path.insert(0, “SomeDirectory”)

# Uncomment to send python tracebacks to the browser if an error occurs:
import cgitb; cgitb.enable()

from mercurial import demandimport; demandimport.enable()
from mercurial.hgweb import hgweb, wsgicgi
application = hgweb(config)

Create a new file called hgweb.config in C:\Program Files (x86)\Apache Software Foundation\Apache2.2\cgi-bin with this content :
/Production = C:/Repositories/Production/*
/QA = C:/Repositories/QA/*
/Dev = C:/Repositories/Dev/*
allow_push = *
style = monoblue
contact =
push_ssl = false

 Add this line in C:\Program Files (x86)\Apache Software Foundation\Apache2.2\conf\httpd.conf in the <IfModule alias_module=””> section :


ScriptAlias /hg “C:/Program Files (x86)/Apache Software Foundation/Apache2.2/cgi-bin/hgweb.cgi

This line allows HTTPD to map the /hg query directly to Mercurial (instead of calling /cgi-bin/hgweb.cgi).
Don’t forget to restart HTTPD.

Step 6 : Test !
Open your web browser at http://localhost/hg and voilà ! You should have this page :


Step 7 : Enjoy
You can now import/clone your repositories


Copy From:

Leave a comment

Posted by on August 12, 2013 in Control Version, Mercurial


Setting up a Mercurial server under IIS7 on Windows Server 2008 R2

This guide walks you through setting up a Mercurial server under IIS7 on Windows Server 2008 R2.

Note: This post uses Mercurial 1.4.3 and Python 2.5.4, although this process will also work with Mercurial 1.5 and Python 2.6.4

Install Mercurial

First you’ll need to download and install Mercurial. I won’t walk through this as it’s a simple case of pressing “next” several times.

Install Python

Next you’ll need to install Python. Note that you need to use the same version of Python that was used to build Mercurial. This guide uses Mercurial 1.4.3 with Python 2.5.4, but if you’re installing Mercurial 1.5 then you’ll need to use Python 2.6 instead.

Be sure to install the x86 version of Python even if you’re running on an x64 system.

Get hgwebdir

Next you’ll need to download hgwebdir.cgi. This is the python script that will allow serving Mercurial repositories through a web server.

Hgwebdir is part of the Mercurial source code, so you’ll need to download the source package to get it. This can be found on the Mercurial site or you can check out the hg source by running the following command:

hg clone

Once downloaded, hgwebdir.cgi is in the root of the source distribution.

Install IIS

Under Windows Server 2008 you can install IIS under the Server Manager and clicking “Add Roles”. Proceed through the wizard and select the “Web Server (IIS)” role.

Under “Role Services” ensure that you enable Basic Authentication as well as CGI extensibility.

Configure Python for IIS

First, create a new directory under the wwwroot directory (C:\inetpub\wwwroot). I’m going to call it “hg”.

In the “Handler mappings” section for this directory select “Add Script Map”:

Next, enter *.cgi as the Request Path and the Executable Path should be set to c:\Python25\python.exe -u “%s”. Enter “Python” as the Name.

At this point, you can test whether Python is working properly by creating a simple python script:

print 'Status: 200 OK'
print 'Content-type: text/html'
print '<html><head>'
print ''
print '<h1>It works!</h1>'
print ''
print ''

Save this in the directory that you created (C:\inetpub\wwwroot\hg) as test.cgi. Now, when you point your browser to http://localhost/hg/test.cgi you should see the following output:

Enabling hgwebdir.cgi

First, copy hgwebdir.cgi (that you downloaded in step 3) and paste it into c:\inetpub\wwwroot\hg. Open this file in a text editor and scroll down to the end. The last lines should look like this:

application = hgwebdir('hgweb.config')

Change the first line to explicitly specify the path to your hg directory:

application = hgwebdir('c:\inetpub\wwwroot\hg\hgweb.config')

Next, you’ll need to unzip the Mercurial library into c:\inetpub\wwwroot\hg. This can be found in under the c:\program files (x86)\Mercurial directory.

You’ll now need to copy the hgweb templates directory into c:\inetpub\wwwroot\hg. This is located in the root of the Mercurial installation directory (C:\program files (x86)\Mercurial)

Finally, create a file called hgweb.config in c:\inetpub\wwwroot\hg. This file can be empty for now (we’ll be putting something in it shortly).

At this point, visiting http://localhost/hg/hgwebdir.cgi will show you an empty repository page:

Configuring Repositories

Now you’ll need to create some repositories to publish. To do this, create a directory in the root of the C:\ drive called “Repositories”. This is where our repositories are going to be stored.

Next, I’m going to create a “test” repository by issuing the following commands:

cd c:\repositories
mkdir test
hg init test

Now we have a repository created, we need to tell hgwebdir where to find it. We can do this by opening up the hgweb.config file we created earlier and adding the following lines:

C:\repositories = C:\repositories

Now, visiting http://localhost/hg/hgwebdir.cgi should display our “test” repository

At this point it should now be possible to clone the test repository from the server with the following command:

hg clone http://localhost/hg/hgwebdir.cgi/test

Pretty URLs

Personally, I don’t like having to specify “hgwebdir.cgi” in the URLs. I’d much prefer something like http://localhost/hg/test to access my test repository.

This can be achived by using the URL rewriting extension for IIS which can be downloaded from Microsoft.

Once installed, you can access the URL rewriting settings though the “URL Rewrite” section of the IIS Manager. Select the “hg” subdirectory in the Connections pane and then select “URL Rewrite”:

In the URL rewrite section add a new blank rule. The name of the rule is going to be “rewrite to hgwebdir”.

Under the “Match URL” section set “Using” to “Wildcards” and set the “Pattern” to “*”

Under “Conditions” we want to ensure that we do not re-write URLs to any physical files, so add a condition for “Is Not a File”:

In the “Rewrite URL” box at the bottom of the screen enter hgwebdir.cgi/{R:1}

The end result will look like this:

Finally, re-open your hgweb.config and add the following section:

baseurl = /hg

This will ensure that hgwebdir generates urls to /hg rather than /hg/hgwebdir.cgi

Now, visiting http://localhost/hg will display our repositories page and http://localhost/hg/test will show our test repository. Likewise, we can now clone repositories using this url format.

Pushing Changes

By default, all repositores served via hgwebdir are read only – you cannot push changes to them. To change this, we can specify the users that should be able to push to the repositores by adding an “allow_push” section to our hgweb.config:

c:\repositories = c:\repositories
baseurl = /hg
allow_push = Jeremy

This means that the user account “Jeremy” (a local user account on the server) will have push access to the repository.

However, if we try and push changes we’ll get an error:

c:\projects\test&gt;hg push
pushing to http://localhost/hg/hgwebdir.cgi/test
searching for changes
ssl required

For now, we’ll disable SSL by setting push_ssl to false in our hgweb.config:

c:\repositories = c:\repositories
baseurl = /hg
allow_push = Jeremy
push_ssl = false

Now when we try and push we get a different error:

c:\projects\test&gt;hg push
pushing to http://localhost/hg/hgwebdir.cgi/test
searching for changes
abort: authorization failed

This happens because by default IIS is serving up our site without authentication. We need to enable Basic Authentication in the Authentication area of IIS:

Now you’ll be prompted to enter your username and password:

After specifying the credetails, the changes will be pushed up. We can view the commit in our web UI:

Enabling SSL

When you use Basic authentication, your username and password will be sent over the wire in plain text. To make this more secure we can enable SSL. For this example I’m going to use a self-signed certificate, although this will also work with a real SSL certificate purchased from a provider.

First, you’ll need to go into the IIS manager, select “Server Certificates” and click “Create Self-Signed Certificate”

Now, add a binding for your Web Site for https on port 443 by right clicking on the site and selecting “Edit Bindings”.

Add a new binding for https on port 443:

Once this is done, you should now be able to access the hgwebdir site by using https (https://localhost/hg). You’ll probably get an invalid certificate warning in your browser.

Now you can re-clone the repository using the secure url (also be sure to remove the “push_ssl = false” line from hgweb.config)

All done!

Leave a comment

Posted by on August 24, 2010 in Control Version, Mercurial


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

Leave a comment

Posted by on July 22, 2010 in Control Version, SVN


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.

Leave a comment

Posted by on July 22, 2010 in Control Version, SVN


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:

Leave a comment

Posted by on July 8, 2010 in Control Version, SVN


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:

Leave a comment

Posted by on April 19, 2010 in Control Version, SVN