Takeaway: Code should have its primary home in a central, well-known location.
The point of source control is to eliminate the guesswork of who has the most recent source code files. This is especially crucial on a project involving multiple developers, as the situation can quickly get out of hand. Eliminate the waste involved in having to manually "diff" files or look at last-modified dates to try to figure out which version of a given source code file is the correct one. Eventually, you'll move on to other projects and someone else will have to maintain this code. Will they be able to find it and feel confident that they have the code that matches what's actually deployed? Source control helps address all these problems.
Several good offerings are on the market today for source control management, including both free/open-source and commercial offerings. Several of the more common/popular ones include: Microsoft Visual SourceSafe, Visual Studio Team System Team Foundation Server, and Subversion (open source). Personally, I like Subversion, so this article uses a Subversion example for instituting source control.
A Quick Introduction to Subversion
Rick Strahl covered Subversion
in his July/August 2008 CoDe Magazine
article. If you're coming from a Visual SourceSafe background, you'll find Subversion's mode of operation is a little different. SourceSafe uses a library approach (i.e., "lock, edit, unlock") mode. Subversion uses a collaborative approach (i.e., "copy, edit, merge"). Using Subversion, you simply retrieve the latest working copy from the server and then just start working on that local copy. When ready, you commit your changes to the repository. Subversion will merge your changes with other people's changes. If Subversion encounters any trouble, it will ask for your help. In my experience, this is rare, but when it does happen, there are powerful tools such as the TortoiseSVN GUI client (more on that later) that can help you deal with merge conflicts easily. Compared to the alternative (having to shout across the cube farm to tell Frank to unlock a file you need), merge conflicts are a small price to pay for all the other functionality in Subversion.
Setting Up a Subversion Server and Repository
The fastest way to get a Subversion repository up and running is to download the free VisualSVN Server
product from the folks that also make the VisualSVN product (a commercial Visual Studio add-in for Subversion interaction).
Install VisualSVN Server on a server or other computer that will be highly available. Don't install the Subversion repository on your developer workstation, because it will hammer disk performance when clients are performing operations—not to mention the problems created if you have to reboot or shut down. You should also set up backups of your SVN repository. This can be as simple as zipping up the repository folder and copying it to another computer or doing a proper backup according to your company's IT backup policy.
After setting Subversion up, you can add users. I wouldn't get too bogged down in configuring their access permissions at this point. That can come later when you're more familiar with the system and your usage patterns.
Installing VisualSVN Server
After downloading the VisualSVN setup package (MSI), run the installer and accept the license agreement. You'll need to enter some important settings (see Figure 1
), including the root path for your repositories, the HTTP/HTTPS port number, and the type of authentication you wish to use.
|Figure 1. Visual SVN Server Options: After you run the installer, you'll see the installer options screen, which requests some settings.|
- Location: This is the location to which the VisualSVN server itself will be installed. I recommend leaving this as the default.
- Repositories: This is the folder into which all your repositories will go (you can have many). I recommend putting this on a separate drive if you have one depending on your performance needs and number of developers using the server.
- Server Port and SSL: Change this if you need to avoid port number conflicts. I recommend leaving this default and using a secure connection. VisualSVN will generate an SSL certificate for you to use internally so you don't have to purchase a full SSL certificate for public use if you don't need to.
- Authentication: VisualSVN Server and Subversion can maintain their own user database, complete with hashed passwords. This is probably the easiest/simplest thing to do to get going quickly. If your organization requires Windows authentication (or you prefer it), use that option instead.
After installing the server, open the VisualSVN server manager (see Figure 2
) to configure your repositories, user security, and other options (no config-file-munging required, unless you really want to).
To create your first repository, right-click on the "Repositories" element in the tree view, and choose the "Create New Repository" option. For the purposes of this article, I called mine MyFirstRepository
. Note that as you type the repository name in the text box, the URL of your repository appears below (see Figure 3
). Before you click OK, you may want to jot this down or copy it to the clipboard for use in a little bit. Next, add users and groups as appropriate. For now, it may be easier to just create a single user that has access to your new repository. While you're here, you may want to create a user called "TeamCityUser" for use later if you configure a Continuous Integration server. Beyond that, you can get fancier with user accounts later. For now, let's proceed with the basic setup.
|Figure 2. VisualSVN Server Manager: Use the Server Manager to configure repositories, security, etc.||
|Figure 3. VisualSVN Server New Repository Dialog: You'll see this dialog when creating a new repository.||
Now that you have a server set up as well as a new repository and associated URL, you can connect a client and start adding code!
Setting Up the Subversion Clients
On your developer workstations, I recommend installing the TortoiseSVN Subversion client for Windows
. It integrates with Windows Explorer and works really well. If you prefer a source control workflow integrated into your Visual Studio IDE, you can use the free, open source AnkhSVN
or the commercial VisualSVN
To keep things simple for this article, I'll use TortoiseSVN as the client, but I strongly recommend you check out Ankh and VisualSVN when you get a chance.
First, on your developer workstation, download and install TortoiseSVN from the link above. Next, decide where on your file system you want the code to reside. Let's say you chose C:\Code
. In Windows Explorer, create a sub-folder called