Tag Archives: svn

Developing and Deploying with Branches

Table of Contents


Getting started with Version Control can be an eye-opening experience. You may have already said to yourself, “How did I work without this?”. Now that you’ve got the basics of Version Control down, you want to start getting really productive by continuing to improve your workflow. Your next step is learning to code in branches.

Coding in branches is a simple practice that keeps you and your work more organised. Branches let you easily maintain your “in-progress” work separately from your completed, tested, and stable code. Not only is this an effective way to collaborate with others, but it will also allow you to automate the deployment of updates, when needed and fixes to your servers.

Coding in master/trunk “branches”

Even if you don’t know how to use branching in your development process, you’ve already been using a branch just by committing your code to version control. In all major version control systems, each repository contains at least one branch by default, your working branch:

  • in Subversion this is a folder called trunk,
  • in Git this is a branch called master.

Without configuring anything, your first commit to any repository will be made to this working branch.

Each version control system has a different approach to creating, merging, and deleting branches. We’ll be focusing on overall development process, and suggest that you refer to the documentation of your preferred VCS for specific details about commands:

Branching Workflow

Using branches can seem complicated without some guidance. We’re going to help you by focusing on two specific uses for branches and the benefits of having them in your workflow.

Benefits of Branches: Building Features & Fixing Bugs

Most coding falls into one of these two categories: you’re either building new features or fixing bugs in an existing codebase. A problem occurs when those two things need to be happen at the same time.

Imagine that you’ve recently launched big Feature X. Things are going well at first, so you move on to start the next task on your to-do list, awesome Feature Y. You start coding and committing changes to your repository, but along the way discover a problem with big Feature X that you need to fix right away. What do you do?

If all of your work is being done in the default working branch of your repository, you’ll need to figure out how to save the work you’ve done so far on Feature Y, revert your repository to the state it was in when you deployed Feature X, make your fix, and then re-introduce your work from Feature Y. This is messy, and you could potentially lose some of your work or introduce new bugs.

Instead, you should be doing all of your work in a feature or bug-fix branches and let the VCS do the hard work for you. You would branch your repository from the point where Feature X was deployed, creating an alternate working copy for you to do new work on. Your Feature Y branch includes the entire repository’s history and code, but a separate history “starts” from the moment the branch is created. This allows you to work on the Feature Y branch, committing to your hearts content, without disturbing the code that you deployed to release Feature X.

Only once the feature is tested and complete, ready for deployment, you can merge that branch back into your main working branch.

This also means you can switch between a feature branch to the default working branch any time to create new branches from that point – like the bug-fix that you need to make. After switching back to the working branch, you would create a bug-fix branch. Working on the bug-fix in its own branch might not seem necessary if the fix is small, but following this practice will help you avoid situations where small bug-fixes turn into bigger bug-fixes, potentially leaving your working branch in a messy state.

Best Practices with Feature & Bug Branches

  • Try to avoid committing unfinished work to your repository’s default working branch.
  • Create a branch any time you begin non-trivial work including features and complex bug-fixes.
  • Don’t forget to delete feature branches once they were merged into stable branch. This will keep your repository clean.

Benefits of Branching: Server Environment Branches

Another reason to use version control is so that you can use your repository as the source to deploy code to your servers. Much like feature and bug-fix branches, environment branches make it easy for you to separate your in-progress code from your stable code. Using environment branches and deploying from them means you will always know exactly what code is running on your servers in each of your environments.

We’ve been talking about your “default working branch” – but you can also think of this as your development environment branch. It’s a good idea to keep this branch clean – this is easily done by using feature and bug-fix branches and only merging them back to your development branch once they are tested. In other words, at any point in time your development branch should contain only stable code. Therefore, we will be using the name “stable” from now on in this guide to refer to this branch.

Using Production and Staging Branches

In addition to your development environment, you’re likely to have at least one other environment:production, where your website or application actually runs. Having a production environment branch and making that the only source of code that goes to production ensures that you have a snapshot of what is on your production server at any time, and a granular history of what’s been added to production and when.

In most cases you will have a staging environment as well, where your team or clients can review changes together. Having a staging environment branch will help you keep that environment with the same benefits as a production branch.

Diff Branches for Easy Code Review & Release Notes

When your development environment has been updated with features and bug-fixes that are tested, you can use your VCS to do a diff between your stable branch and staging branch to see what would be deployed that’s not currently on staging. This is a great opportunity to look for low quality or incomplete code, debug code, and other development leftovers that shouldn’t be deployed. This diff can also be helpful in writing your release notes.

Never Merge to Environment Branches Without Deploying

In order to keep your environment branches in sync with the environments, it’s a best practice to only execute a merge into an environment branch at the time you intend to deploy. If you complete a merge without deploying, your environment branch will be out of sync with your actual production environment.

With environment branches, you never want to commit changes directly to the branch. By only merging code from your stable branch into staging or production branches, you ensure that changes are flowing in one direction: from feature and bug-fix branches to stable and staging environments, and from stable to production. This keeps your history clean, and again, lets you be confident about knowing what code is running in which environments.


Best Practices with Environment Branches

  • Use your repository’s default working branch as your “stable” branch.
  • Create a branch for each environment, including staging and production.
  • Never merge into an environment branch unless you are ready to deploy to that environment.
  • Perform a diff between branches before merging—this can help prevent merging something that wasn’t intended, and can also help with writing release notes.
  • Merges should only flow in one direction: first from feature to staging for testing; then from feature to stable once tested; then from stable to production to ship.

Further Reading: Branching with Beanstalk

This is just an overview of some of the most common practices for using branches in version control. If you’re using Beanstalk, we’ve included some resources to help you take advantage of branching.

Original Article

TFS, SoureSafe or Subversion

Quite often when I start at a new client they ask me what are the benefits of TFS (Team Foundation Server), as they can not justify the cost, as it is very confusing (like may of Microsoft pricing structures)

I found this about “How much does Team Foundation Server REALLY cost vs SourceSafe?” by Eric Nelson, which is just what I have been looking for, as you can see the cost is not that much more than SourceSafe, and you gain huge benefits from TFS, as it is not just a Source Control, it’s much much more.

Create SubVersion on an Internet machine via port 80


It’s nice to use SubVersion locally, after seeing that CodePlex now supporting SVN over HTTP, I thought I’d give it ago.  

Here all all the steps for allowing you to use SVN via port 80 and SVN:

The subversion server, download the source, not third party application, installer at 


does not include Apache, it includes the subversion modules that work with apache but not apache itself.


After installing the package you will need to set svnserve up to be a service, there are instructions for this at:


Essentially you need to do:

md c:\subversion-repositories

sc create Subversion binpath= “c:\program files\subversion\bin\svnserve.exe –service -r c:\subversion-repositories” displayname= “Subversion Server” depend= Tcpip



net start Subversion


This sets up the subversion service and starts it, you will then need to create your repository

“c:\program files\subversion\bin\svnadmin” create c:\subversion-repositories\repos


You now have a svn server running with a repository called my-repos available at svn://<server-ip>/repos


At this point the repository will be set to anonymous read access and auth write access but will not have any authentication setup, to set this up go into the c:\subversion-repositories\repos\conf folder and edit authz and passwd files to setup the permissions, they are comments and fairly easy to understand.

I’ve attached two working examples for authentication, to help the configuration.

svnserve.conf (413.00 bytes)

passwd (51.00 bytes)

What do you need to get SubVersion working in Visual Studio 2008

What do you need to get SVN to working within Visual Studio 2008?

You should only need AnkhSVN, as this is an AddIn for Visual Studio 2008.  But it is worth getting Torroise SVN to allow for access to SVN via the file manager.

If you need to run SVN on your machine to hold the safe then you’ll need SubVersion

Once you have SVN installed it is always worth adding a global ignore pattern to TortoiseSVN, he is one that Jonathan Merrifield provided me with. 


Put this in TortoiseSVN -> Settings -> Global ignore pattern

*.o *.lo .la ## .*.rej .rej .~ ~ .# .DS_Store thumbs.db Thumbs.db *.bak *.class *.exe *.dll *.mine *.obj *.ncb *.lib *.log *.idb *.pdb *.ilk .msi .res *.pch *.suo *.exp .~ .~ ~. cvs CVS .CVS .cvs release Release debug Debug ignore Ignore bin Bin obj Obj *.csproj.user *.user 

A nice article worth having a look at is by Alexey Smirnov, Version Control, article below


Version Control

Getting Started with AnkhSVN and Subversion

By Alexey Smirnov

There are a few version control solutions for ASP.NET out there on the market. One of them is a new version of AnkhSVN. AnkhSVN 2.0 is a free Subversion client, implemented as a package for Microsoft Visual Studio 2005 and 2008. It provides an interface to perform the most common revision control operations directly from inside the VS.NET IDE.

This article provides an introduction to AnkhSVN by describing how the product works and explaining its main operations.

As mentioned above, AnkhSVN is a Subversion client; in other words, an interface between Subversion, a free open-source version control system, and Visual Studio .NET. On its own, Subversion allows one to track and store code changes, collaborate, and share project files. All information about project files is saved to a repository, a simple directory structure. To create and manage a repository you would need to install Subversion or one of several other third-party client applications. For this purpose, this article used TortoiseSVN, a standalone Subversion client.

There are many good reasons for AnkhSVN and TortoiseSVN cooperation. While TortoiseSVN has all the necessary commands to work with Subversion and can be used as a standalone version control tool, AnkhSVN focuses on automating common tasks for Visual Studio developers and integrating to the IDE. Used together, both tools can provide everything needed to make the development process quick and easy.

The most recent versions of AnkhSVN and TortoiseSVN can be found on their official Web sites: http://www.ankhsvn.com and http://www.tortoisesvn.net.

Once AnkhSVN and TortoiseSVN have been downloaded and installed, it is required to create the initial repository. To accomplish this, first create a new folder. TortoiseSVN extends Windows Explorer and all commands are available from its context menu. Right-click on the new folder and access the TortoiseSVN menu. Select the Create Repository Here option. 

Start Visual Studio and make sure AnkhSVN is the active source control provider. Open Tools | Options | Source Control and check that AnkhSVN is already selected.

Open a project in VS.NET. From File Menu | Subversion | Add add the solution to Subversion. In the Add to Subversion dialog box add the Repository URL created in the previous step. For a directory located at D:\SvnRepos the URL will be file:///D:/SvnRepos/.

After that you’ll see in Solution Explorer a blue plus sign (+) next to each file. This means your files are ready to work with Subversion. To add files in the repository, open the context menu in Solution Explorer and click Add, then click Commit. You’ll see green checkmarks alongside items in Solution Explorer. Now your project is under version control and the initial version of the project is saved in the repository.

AnkhSVN adds to Visual Studio a new Pending Changes window to show all changes in a single location rather than having to navigate through Windows Explorer or even Solution Explorer. Once you start to make changes, you’ll see modified items added to the Pending Changes window. This window is accessible through View | Show Pending Changes.

If a project has been modified and new revisions were added in a repository, you can restore the revisions by using Update and View History in the context menu of Solution Explorer. To restore the previous version, go to Update | Revision | Previous. To get back to the specific revision, open View History and find the number of the revision you want to get back. Then open Update and specify the number to get the right revision.

Update and View History can be applied concurrently to multiple files. To restore a single file you may use Revert to get the revision menu from Solution Explorer.

You’ll get a more advanced interface to work with the repository in TortoiseSVN. Go to Windows Explorer. In the context menu find TortoiseSVN | Update to revision, where you can choose which revision has to be restored in the project directory.

One of the features of a version control system is the ability to isolate changes onto a separate line of development. This line is known as a branch. Branches are often used to try new features without disturbing the main line of development with compiler errors and bugs. As soon as the new feature is stable enough, the development branch is merged back in to the main branch (trunk). Another feature of a version control system is the ability to mark particular revisions (e.g., a release version) so at any time you can recreate a certain build or environment. This process is known as tagging.

Subversion combines these two processes into one. Create Branch/Tags is available in TortoiseSVN through the context menu Branch/Tags. Specify the URL for the new branch; for example, “project_url/1.0” where “1.0” will be the name of the branch. Use the Switch working copy to new branch/tag checkbox if you want your working copy to be switched to the newly created branch.

After that you can work on the project as usual and when you need to return the whole project back to version 1.0, use the Update to revision command.


The new release of AnkhSVN is fast and stable compared to the earlier versions — and a good alternative to other source control solutions for ASP.NET developers. This article covered typically used commands of AnkhSVN and explained main steps to start working with AnkhSVN and Subversion. More information about Subversion and other third-party clients can be found at http://subversion.tigris.org.

Alexey Smirnov is an IT consultant and a Microsoft MVP. You can reach him at mailto:alexey.smirnov@gmail.com.