Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Speed Up Project Delivery with Repeatability : Page 2

Automate high-friction, unpredictable tasks in your environment to regain sanity and achieve a rapid, sustainable pace.




Application Security Testing: An Integral Part of DevOps

Source Control

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
Author's Note: If you've used Visual SourceSafe previously, the term "Checkout" in Subversion parlance, is close to the concept of "Get Latest Version" in VSS. When you're initially getting the source from a Subversion server, use the "Checkout" command.

Figure 4. TortoiseSVN Initial Checkout: You need to know the repository URL, and specify a directory to place checked-out files.
Next, you will be prompted to enter the repository URL and a few other options. This is where the repository URL of the repository you just created will be necessary. See Figure 4 for an example.

Once you have filled in these options and clicked OK, and since this is the first time you've connected to this repository, TortoiseSVN will ask you whether you trust the SSL certificate for this server. I recommend you choose "Accept Permanently." Next, you will be asked to enter your username and password. Use the credentials of the user you created above. You have an option to remember these credentials so you won't have to be prompted for them every time. I recommend doing this as having to type in your login and password every time you touch the repository can be very annoying.

At this point, Tortoise has everything it needs to connect to the repository and perform a checkout. You should see a screen similar to Figure 5. You've now set up the repository file system. You can now add, update, and delete code and other artifacts of your project.

Setting up a Global Ignore Pattern

Figure 5. TortoiseSVN Checkout Status Dialog: This status screen shows the status of files in your project.
One last thing you might want to do, before you start seriously using TortoiseSVN, is to set up your "ignore" list. By default, SVN allows you to put whatever files you want in the repository. There are several types of files that you probably don't want in your repository at all. These include things such as compiled output (i.e., the \bin\Debug folder), the Visual Studio user-specific .suo and .user files, and other machine-specific or transient-type files.

To do that, right-click on any folder and navigate to the TortoiseSVN menu, then choose "Settings." You'll see a dialog box. In the "Subversion" group, find the textbox labeled "Global ignore pattern." Enter your ignore pattern(s) here. As an example, the snippet below shows the ignore pattern I use. Feel free to customize it for your environment.

Bin */Bin bin */bin obj */obj *.suo *.csproj.user *.log *.log.* *.rdl.data *.rptproj.user _ReSharper* *.resharper.user build */build

The preceding ignore pattern filters out all the files in bin\Debug, bin\Release, and obj folders, as well as temporary log files, user settings, the ReSharper (if you use ReSharper) cache folder, and any "build" products you may have, preventing TortoiseSVN from storing those unwanted files in the repository.

Workflow of a Subversion User: The Check-in Dance

Now that you have the repository up and running and you have a local folder, here's how to add some code. Assume you already have an existing project. Create a folder under the trunk folder called source and add your existing code folder(s) under there. Right-click on the source folder and click "Add" to add all your existing files, and then right-click on source and choose "Commit." Type in a message, and then click OK. That sends your first code commit to the repository. The code you committed is the code that other developers will get when they connect their clients and perform an "SVN Checkout." Congratulations! Now your code is in a repository. This is a first, major step towards adding repeatability to your process.

A Subversion user's typical day goes something like this (colloquially known as the "Check-in Dance"):

  1. Start work, perform an "Update": Right-click on your "trunk" folder in Windows Explorer and choose "SVN Update." TortoiseSVN will now retrieve any updates that other developers have committed since you last updated.

  2. Resolve any conflicts and review any interesting changes: In the TortoiseSVN update status window, you will see a list of files that have changed and their disposition (updated, merged, conflict, added, deleted, etc). If, for some reason, Subversion could not merge one or more changes from other users into your code tree, you will have an opportunity to resolve the conflict. If you know their version is correct, you can right-click on the conflicted file and choose "Resolve conflict using theirs." If you're sure your version is correct, you can choose "Resolve conflict using mine." If there's no clear answer, select "Edit Conflicts" to use the TortoiseMerge tool to perform a manual merge. This is usually not a pleasant task, but the tools in Tortoise make them relatively simple.

    Of course, you can always manually merge the file in your favorite text editor/IDE, but the visual cues in TortoiseMerge can be compelling for most circumstances (see Figure 6).

    Merge problems can sometimes occur if you make changes locally to the code during a refactoring, but haven't yet committed the change and another user made similar changes.

    In addition to managing conflicts, you can also right-click on files that changed and see the differences in Tortoise's Visual Diff Viewer application.

    Figure 6. TortoiseMerge: Use the TortoiseMerge application to help handle change conflicts.
  4. Start making changes: After integrating changes into your local copy, you can start coding normally—that is, you should code as though no source control were in place. Add, remove, and change files as necessary; don't worry about locking or unlocking files, etc.

  5. Update to integrate the latest code: When you complete your code changes and are ready to commit them to the source control repository, you should do one more update just in case there are any late-breaking changes that you should be aware of that might cause an integration issue with other developers. Subversion will notify you that other people have committed to the repository since the last time you updated, and in most cases will not allow you to commit until you've done another update. After you've updated and resolved any conflicts, you should consider running any test suites or verification programs you may have set up in your process.

  6. Commit your changes: Finally, when you're ready to commit your changes, right-click on your trunk folder in Windows Explorer (or you can use the IDE-integrated experience if you're using the VisualSVN or AnkhSVN Visual Studio plug-ins) and choose "SVN Commit." At this point, take a minute to look at the list of files that Subversion thinks should be committed. Make sure that any files that need to be added are marked as "added" and will be uploaded to the repository. Next, type in a descriptive message that describes what's in this update you're sending, and perhaps why the changes were being made. Trust me, these comments help you when you have to come back two months later and look at commit logs to figure out why you made a particular change to this file. When you're ready to commit, click OK to start the commit upload process.

  7. Resume work: If you're not yet done for the day, at this point you can resume working on your code and start the process over again.
For people not used to source control, this process may seem like a lot of extra work, but it's not as hard as it sounds, and only rarely is it ever more than a minor annoyance. It's far less painful and annoying than fighting for locks to a file or dealing with the "Jim went on vacation and left half the source tree locked… again" sort of problems you have with lock/edit/unlock style source control systems.

The Check-in Dance helps maintain a high level of integration among developers and also encourages a sort of "source hygiene" that discourages people from committing bad (i.e., build-breaking) changes that can slow down your team at the worst times.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



We have made updates to our Privacy Policy to reflect the implementation of the General Data Protection Regulation.
Thanks for your registration, follow us on our social networks to keep up-to-date