Part I: Beginning the CI Journey with Subversion
<UPDATE>2008-03-20: As noted by Stefan, we don’t need to check the “Use ‘_svn’ instead of ‘.svn’ directories” checkbox of TortoiseSVN’s settings if you’re using Visual Studio 2005 or Visual Studio 2008.</UPDATE>
In this section, I’m going to describe how to properly install and configure Subversion in Windows. At the moment of writing this post, the latest version of Subversion is 1.4.6. I’ll do my best to update this post to reflect the latest version of the tool in the future.
My strategy for Subversion is to install it in a dedicated machine. It’s recommended for Subversion to be independent of the build integration server, so that if you must update and restart the integration server, the developers will still be able to access the repository.
=> Step 1. Make sure that the host operating system where you’re going to install Subversion is running at a minimum Windows XP SP2, Windows Server 2003 or Windows Vista.
=> Step 2. Download the Subversion installation file svn-1.4.x-setup.exe (Win32 binaries) or svn-1.4.x-setup.zip file from the following URL: http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91. The Win32 binaries executable file is your typical Windows software installation process (Next->Next->Finish). If you’re downloading the ZIP file, just extract its content somewhere in your drive, such as in c:\Program Files\Subversion. At this point, you’re just installing Subversion. You’ll create a source repository at step 5.
=> Step 3. Verify that the path to the Subversion bin directory is present in the %PATH% environment. If that’s not the case or if you have extracted the executable files from the ZIP file, make sure to add it manually before continuing. For instance, if you have installed Subversion under c:\Program File\Subversion, then make sure to append the c:\Program Files\Subversion\bin path to the %PATH% environment. Do not reboot the system yet, because there’s still another environment variable to add in the next step.
=> Step 4. Add the SVN_EDITOR environment variable. This is required so that Subversion can launch an external text editor whenever necessary in order to edit some data associated to a repository. The value for this environment variable must be the full path to your favorite text editor. For example, if Notepad is your primary text editor (as Seinfeld would say, not that there’s anything wrong with that), the SVN_EDITOR environment variable should have its value set to c:\windows\notepad.exe. You may now reboot the machine if necessary.
=> Step 5. Create a source repository for your development projects. I recommend starting with one repository for all your projects and then scale or change your strategy as you get more comfortable with the tool. The following steps will guide you in creating a Subversion repository.
=> Step 5.1. Launch a DOS command prompt window.
=> Step 5.2. Type the following command which will create a new repository using FSFS as the default file system of the repository (you can read more about that file system in Subversion’s documentation, which is by far the best documentation for an open source project):
svnadmin create "<repository path>" |
where <repository path> is the location where you would like to create the repository. For instance, if I want to create the repository in d:\repository, then I will type the following command:
svnadmin create "d:\repository" |
The svnadmin command tool will create the directory if it doesn’t exist. The quotes are necessary if the pathname contains spaces.
=> Step 5.3. Go to the repository’s path and edit the svnserve.conf file under the conf directory.
=> Step 5.4. Uncomment the following lines under the [general] section of the file to setup the default security permissions (you can also read more about Subversion’s security permissions and mechanisms in its documentation)
[general] anon-access=read auth-access=write password-db=passwd |
=> Step 5.5. Save and close the serve.conf file when done editing the file.
=> Step 5.6. Under the same conf directory, edit the passwd file and modify it to include the user accounts and passwords for each team member who will have access to the repository. The format is that of a key-value pair. The key corresponds to the username, and the value corresponds to the user’s password. The password is in clear text which pretty much sucks, but if you really need password discretion, I suggest you look into a tool like this one.
[users] alice=alice-passwd bob=bob-passwd charlie=charlie-passwd |
IMPORTANT: Also, add a TeamCity account so that it’ll have access to the repository.
=> Step 5.7. Verify the repository’s integrity by typing the following command:
svnadmin verify "<repository path>". In our case, we'll type svnadmin verify "d:\repository" |
=> Step 6. Create a Windows service to automatically start the Subversion server (svnserve.exe) whenever the host operating system starts. Type the following command to create the Windows service:
sc create svnserve binpath= "\"c:\Program Files\Subversion\bin\svnserve.exe\" --service -r <repository path>" displayname= "Subversion Server" depend= Tcpip start= auto |
In our case, <repository path> will be the repository path created in step 5.2 (d:\repository). Be sure not to forget the quotes if your repository pathname has some spaces. It is also important to note that there is a space between the SC command property and its value!
=> Step 7. Start the Windows service by executing the following command:
net start svnserve |
In the same manner, you may stop the service by executing the following command:
net stop svnserve |
|
Before we continue with installing TeamCity, it is important to start planning your backup strategy for the repository. I’ll leave that strategy to you. The following command can be executed as a CRON job or as a Windows scheduled task to backup your repository:
svnadmin hotcopy "<repository path>" "<target path>" --clean-logs |
Then backup the <target path> somewhere place in case of an emergency.
Finally, each developer should install a Subversion client in order to easily access the repository within Windows Explorer and Visual Studio 2005/2008. I recommend using TortoiseSVN because it integrates quite nicely with Windows Explorer and its documentation is very excellent. As for Visual Studio, I recommend using either AnkhSVN (open source) or VisualSVN (commercial). Concerning TortoiseSVN, make sure to check the checkbox “Use ‘_svn’ instead of ‘.svn’ directories” if you’re using Visual Studio .NET 2002/2003. You’ll need to restart the machine to apply the changes. The reason we need to check that option is because Visual Studio .NET 2002/2003 seems to have some issues with folders that start with a period. This issue doesn’t apply if you’re using Visual Studio 2005/2008.

Similar posts you might be interested in reading:
- Quick access to useful documents inside Visual Studio
- Copy files from build events within Visual Studio without Windows UAC problems
- Part II: Setting Up Our Build Server With TeamCity
- Customizing your command prompt
- Integrating Enterprise Library 3.1 Configuration Tool in Visual Studio 2008
- Launchy: A Good Alternative To The Start Menu
- Mapping a shortcut to execute unit test in current context with ReSharper






Stefan:
The problem with .svn folders in Visual Studio has been fixed for VS2005 and later. It’s therefore not required anymore to use the _svn folders for those versions of Visual Studio – only VS.NET2002 and VS2003 are affected.
March 20, 2008, 1:27 amIvan Zhakov:
Take a look to VisualSVN Server (http://www.visualsvn.com/server). It performs all this stuff in one click. It also contains nice GUI for managing repositories and permissions. And it’s free
March 20, 2008, 3:50 amBrian Di Croce:
==> Stephan,
Thanks for the update on this issue. I’ll update the post later today to reflect this information.
==> Ivan,
March 20, 2008, 6:39 amVisualSVN Server is an excellent solution indeed. No doubt that VisualSVN Server deserves a post on its own. We’re actually using VisualSVN for our Visual Studio integration with Subversion…it simply rocks! I’ve yet to try AnkhSVN on VS2008 to see if it works well or not. After this series, I’ll make sure to write about VisualSVN as an alternative to Part I of the series (this post).