Subversion Quickstart for .NET Developers

Listen to the show
- listen now
- download
Watch the video
- watch now
- download (You'll need the Swiff Player to watch on your machine)

Note: This is the first part of a series on Subversion from the Polymorphic Podcast. Soon there will be a video portion to accompany the audio introduction to this topic. The video will cover:

Installing and configuring the Subversion repository
Installing and using TortoiseSVN
Initial check-outs
Comitting changes
Merging changes

Subversion

Subversion, sometimes known as SVN, is an open source version control system. Subversion allows users to keep track of changes made over time to any type of electronic data. Typical uses are versioning source code, web pages or design documents.

Why Subversion over Visual Source Safe?

While Visual Source Safe (VSS) is fully integrated into the Visual Studio environment, there are many disadvantages that can not be ignored.

Reliability

Sam Gentile, in his blog post entitled "No More VSS, Its Subversion", is so bold to just link to the search terms "VSS+corrupt" on Google to make a case for the ubiquity of VSS problems.

Numerous accounts of crashing and corruption: See links above...
Not a client-server application: The current VSS setup makes it difficult to expose source code to developer's outside your network.
Database size restriction: Some say the limit is 2GB, others say 10GB. Even if it's 100GB - who want's to worry about a size restriction?

Preferential Issues

There are also a number of issues with VSS that are most fairly described as "preferential issues". I cite these issues because while they are not technically "bugs" they do represent limitations that many developers find as a hurdle to deal with in the real world. Examples of some of these issues are exclusive file locking and VSS's method of tagging and branching make it difficult at times to work with.

Operation

Subversion features the operations you would come to expect from any source control system. If you come from a VSS background, some of the terms may seem a bit awkward. Below is a list of the most common operations you encounter while using Subversion.

Trunk

The trunk is the main thread where you will often work on your source code. The trunk acts as the basis where you can branch off and make changes or create point-in-time copies of your code. The trunk, just like a tree, is what supports a source code project.

Checkout

As opposed to a "check out" in VSS, a Subversion checkout is when you contact the code repository for the first time and bring down the files on to your machine. When you do a checkout the file and directory structure is created on your computer and a hidden folder is created under each folder under source control that helps maintain the state of each file.

Add

When you want to add a new file to the source control repository, you must first mark the file as being added. This will signal to Subversion that the next time you synch up with the repository, the file must be copied from its location on your machine to a versioned state on the Subversion server.

Commit

Many changes that you make to files will require a two-step process to expose the changes to other users of the repository. After you have added or changed a file, you must commit the changes up to the Subversion server. This will allow you to make many changes, but submit all the changes to the repository in a single transaction. Changes to the repository are atomic actions.

The two-step process also enables Subversion to keep the code repository's integrity while not requiring a exclusive lock on files under source control.

Conflict Resolution

When multiple people are working on the same project, inevitably they will end up editing the same file at the same time. When this happens there is a conflict in file states that must be resolved. When you go to commit your changes to Subversion, if a conflict is detected you will have an opportunity to resolve the conflict. Some of the UI tools make the experience prettier, but the process is the same whether or not you are using a GUI tool or the command line. Conflict resolution will expect you to choose portions of a file or entire files all together as the file version of the file. You do have an opportunity to say, "give me this section from file 1 and this section from file two" in order to reliably keep everyones changes. Conflict resoution is usually a non-event as often two developers are not working on the same line of code in the same file. If the changes in question are on the same lines of code among what the developers changed, then a decision must be made as to who's changes to keep and the application must be tested or perhaps refactored to not break this build.

Branching

A feature that Subversion implements well is the branching feature. Rather than maintaing some huge change log off the main repository thread as to what a "branch" is, Subversion makes a copy of the trunk and allows you to make any changes necessary. To bring the changes back down to the trunk you will merge the changes down to the trunk.

Merging

Once you have created a branch that you need to bring down to the trunk you will run a merge operation. Merging a branch down to the trunk is equivalent to comitting a large-scale change to the repository. If there are any conflicts during a merge Subversion will give you a chance to resolve the conflicts.

Tagging

Tagging gives you a way to set aside the trunk at a point and "label" the state of the trunk.

Branching vs Tagging

Often people wonder what is the difference between branching and tagging. You use a branch when you want to make significant changes to the trunk and still need source control features of commiting changes to the server, but don't want those changes to effect the users of the trunk. Branching creates an isolated environment for someone to make changes to the code.

Tagging is best used as a point-in-time snapshot of the repository. For instance at each version release of your code you would want to tag the code base.

Integration

When someone says they have Subversion installed on thier machine, often they mean they have a Windows Exporer shell installed and not the server on the box. Subversion is a client-server application where the service, security and database all live on a single server and clients (developer machines) use a separate tool for accessing the repository. The most common tool on Windows is Tortoise SVN.

Tortoise SVN

File system integration is seamless. Tortoise SVN is a Windows Explorer shell extension that grants you access to the Subversion repository natively from Windows Explorer. If you right-click in a Windows Explorer window you immediately have access to the Subversion system. The greatest benefit from granting access from a shell extension is that the access is pervasive. Any window that grants you listing of the file system will expose the Tortoise menu (ex: File-> Open dialog boxes).

You may download Tortoise SVN here.

As a .NET developer, there is one issue that you must be aware of before you begin using Tortoise SVN for your Visual Studio projects. Tortoise SVN uses hidden folders within the file system to help maintain the link with the central repository. These hidden folders are by default named ".svn". You will find this folder under every folder that is under source control with Tortoise SVN.

For some reason, the ".svn" naming convention is nothing but trouble to the Visual Studio IDE. If you try to use Tortoise SVN using it's default settings you will eventually encounter the following error while trying to run your projects and solutions in Visual ] Studio:

Cannot load project information from server

While this is technically an error stemming from a problem in the Visual Studio IDE, the Tortoise development team seemed to concede that it was easier to make a small change in the Tortoise setup rather than wait for an update to Visual Studio.

Therefore before you begin using Tortoise SVN for the first time, be sure to change the settings for Tortoise to use a hidden folder named "_svn" rather than ".svn".The following section will walk you through the process.

Configuring Tortoise SVN for use with Visual Studio

Once Tortoise SVN is installed on your machine, open a Windows Explorer menu and right-click to open the context menu. From the menu do the following:

Select TortoiseSVN
Select Settings
Check the box labeled Use "_svn" instead of ".svn" directories
Click OK

Then you are prompted to reboot your machine. While the reboot is annoying, it is required.

Note: The change in directory setting is appropriate for all Visual Studio versions, not just for Visual Studio 2003.

Visual Studio

When you begin using Subversion, you will appreciate the ease-of-use and performance, if you do not have a way to integrate with Visual Studio you will find it hard to use. Particularly if you have to somehow keep track of which files were added to your project and so on.

There are at least two options available to you to integrate access to the Subversion repository from within the Solution Explorer inside Visual Studio.

AnkhSVN: AnkhSVN is free and provides the same types of services that you would expect from VSS integration with Visual Studio. The only downside to AnkhSVN is that the UI implementation sometimes feels a little clunky. Asethetics aside - AnkhSVN is a solid program which allows you to seamlessly integrate with the Subversion repository.
VisualSVN: VisualSVN is much like AnkhSVN, but the UI experince is cleaner. Also the icons used in the context menus are exactly the same as in Tortoise SVN. This little touch just makes it easier to keep track of what operations you are performing since the experience looks the same in and out of the exporer shell. Functionally though VisualSVN's capabilities are equivalent to AnkhSVN. VisualSVN is not free.

Continuous Integration

One of the great benefits of working with a source control sysetm that is open source and extensibile, is how it will interface with other components in the development lifecycle.

Subversion integrates with many of the open source continuous integration packages as well as with MSBuild.

Resources

Note: Opening up access to your repository over the web can prove difficult on a Windows machine. Many people setting up for remote access will configure the repository on a Linux box running Apache.