Arctus Blog

Subversion is the perfect tool for versioning .NET projects. I assume that you have a working subversion environment (see my earlier article if not) and have created a repository to hold your project.

I am using a subversion server on my localhost and my repository is named after my project, cryptically known as ProjectX.

I am going to explain the process of creating a project from scratch and adding it to subversion. It is easy enough to change this for use on existing projects, just skip the earlier steps.

Please also note that I am using the Web Application Project add-in (also included in Service Pack 1) because I like things to work. I strongly recommend all ASP.NET developers opt to use Web Application Projects.

Create the Project Files

First of all, we create an empty solution (File -> New -> Project…, Other Project Types, Visual Studio Solutions, Blank Solution) [Fig 1].

My solution’s folder is C:\Development\ProjectX. We will create two projects in our solution. Right click the solution (in VS2005) and choose “Add -> New Project…” [Fig 2]. For most projects, you will want at least one class library (for your model) and a website. I created two projects, CoreLibrary and Website [Figs 3 & 4]. You should also set basic configuration options now (include folders, references etc).

Cleaning up

Before we add our folder to Subversion, we want to make sure that we don’t check in folders that contain binary output. Such files and folders change every single time we compile, and thus become meaningless noise if they appear in every single commit.

You should delete the .sou file in the solution folder, and your should also delete the bin and obj folders that appear in all of the sub-project folders.

First commit

Having deleted these files and folders, we are ready to commit. Right click the solution folder (ProjectX, in our case) and choose TortoiseSVN -> Import [Fig 5].

I always create a Trunk folder in my repository where the development happens (this allows me to create branch folders when I need a snapshot of development at a point in time). Thus, my url is:

svn://localhost/ProjectX/Trunk

[Fig 6]. If I didn’t want a Trunk folder, I would just lop-off the word Trunk from that url. You don’t need to manually create the Trunk folder – it will be created when you perform the import.

Click OK, and our files are added.

Getting a working copy

This is an important step. If you miss it out you will not be able to commit your changes.

First, delete (or move) the folder that contains your solution and then create an empty folder of the same name.

Now right click the empty folder and choose ‘SVN Checkout’. The url should be correct already. If not, use the url that you entered above during the import.

Click OK and your folder will be updated and the project built from Subversion. The icons should have little green ticks to indicate that they are unchanged from the server versions.

Cleaning up, again

Now re-open your solution and compile everything (or run the application). When you have done this, close the solution and go back to Windows Explorer.

We’re going to update properties on several of the solution folders, so we must first right click the solution folder (ProjectX) and choose SVN Update. It will say “completed at version 1” without actually doing anything. It is important that we do this, before updating properties (though I am not sure why).

If you look inside the project folders you will notice that the .sou file and the bin and obj folders have been re-created, but are not versioned. We need to tell subversion to ignore these items. Right click the solution folder (ProjectX) and choose SVN Commit. Don’t click OK yet.

In the list of modified files you will need to right click the .sou file and choose Add To Ignore List -> FileName.sou (where FileName is the name of the project). It will disappear from the list.

Now you need to do exactly the same thing for all of the bin and obj folders only (i.e. not their contents).

When this is done you will see that the project root-folder (.) and the sub-project folders are identified as being modified. This is because we have just set their properties to ignore those selected files and folders. When we commit, those properties will be written back to the server. Click OK and it should say “Completed at version 2”.

Your solution is now ready for development.

Working in a team

All developers on the team will need to checkout the source from the subversion repository.

When a developer is ready to commit, they must first run SVN Update on their local copy of solution. This fetches all changes made since their last update. You don’t need to close Visual Studio to do this, but you might get notices that files have changed if you don’t.

SVN Update can identify and often resolve conflicts (where two developers change the same file). Sometimes, it is unable to automatically resolve conflicts. These occurances are rare. The supplied TortoiseSVN tools are excellent, and make it clear where the problems are. If the conflict is not easy to resolve, it is important that the developers can sit together to go through the changes and choose which stay, which go, or how best to merge. To merge, you should locate the conflict area in the bottom most window panel and right click the conflicted block. You can choose from theirs, mine, theirs before mine etc. Once done, click the little ‘resolved’ icon (an explanation mark) and then the save the file.

Unless your code base is a spaghetti mess, you won’t have serious conflicts too often. If it is a spaghetti mess, you still shouldn’t get that many unresolvable conflicts, but maybe it’s time for a spring clean?

The developer can now commit. However, before doing so they must ensure that the project still builds and that unit tests still pass. The cardinal sin to commit code that doesn’t build – there is no excuse.

Once you are familiar with these steps, the process of updating and committing becomes quite a rapid and exceptionally useful exchange. Because a developer’s update is applied in a single transaction, we know that the files that have changed are related to just one area of functionality. Thus, to perform an update and find that we can no longer compile is not a serious problem – tracking down the changes is very easy indeed. Of course, the longer the other developers wait between Updating their own projects (you don’t need to do it just before a commit, you can do it as often as need be) the more changes will be rolled in to one update, but it is still extremely useful and a world away from the lock -> update -> release mind-set of Source Safe.

Feedback

Please let me know if you have any questions or comments.