Component Workshop Ltd

I will assume that you already have a working Subversion repository to hold your project (if not, take a look at our managed hosting platform CodeSpaces!)

I am going to explain the process of creating a .NET solution from scratch and adding it to subversion. It is easy enough to adapt these instructions and use them for existing projects.

Create the Project Files

First of all, we create an empty solution in Visual Studio (File -> New -> Project..., Other Project Types, Visual Studio Solutions, Blank Solution). You must provide as path for your solution (I use C:\Development) and a name. In this example, I have called my solution ProjectX and my folder is C:\Development.

I will create two new sub-projects in my solution. One will be a class library, and one will be a web application. Still in Visual Studio, right click on the solution in the solution explorer and choose "Add -> New Project...". I have created two projects called Model and Website. If you need to configure references or include any 3rd party DLLs, you can do that now (if I use 3rd party components, I typically create a folder called Libraries in my solution folder -- I.E., C:\Development\ProjectX\Libraries, so that the DLLs are source controlled along with the source code).

Before we add our project 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 close Visual Studio, and then delete the .sou file that it has created in the solution folder. You should also delete any bin or obj folders that have been created in the sub-project folders (if you built or ran the solution).

First commit

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

I always create a 'trunk' folder in the root of my repository. This is a convention that is widely adopted -- primary development happens to code in the trunk and you create branch and tag folders when you need a snapshot of development at a point in time. In the import window, if you append trunk to the url of your repository, the folder will be created for you. My repository url for the import is:

http://svn.codespaces.com/example/projectx/trunk

Click OK, and your files are added to the repository.

Getting a working copy

This is an important step. You should now move or rename your project folder to another location, and get a new, working copy from Subversion. If you miss this step out and make changes to the folder and files that you just imported, you will not be able to commit those changes!

Once you have deleted, moved or renamed the project folder, you should 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 populated with the project files you just added to Subversion. The icons should have little green ticks to indicate that they are unchanged from the versions in Subversion.

Cleaning up, again

Now re-open your solution in Visual Studio and compile everything (or run the application). When you have done this, close the solution and go back to Windows Explorer. This will cause bin and obj folders to be created for your projects, and an suo file will appear in the project's top folder.

We’re going to use Tortoise to update the properties on several folders to ignore these files, but first we must first right click the solution folder 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 don't Update first, your next commit (with the ignore commands) will fail.

Right click the solution folder and choose SVN Commit. The commit window will appear. Don’t click OK yet.

You can right-click on the files in this window and perform certain actions. You will need to right click the .sou file and choose 'Add To Ignore List -> FileName.sou' (where FileName is the name of the solution It will disappear from the list.

Now you need to do exactly the same thing for all of the bin and obj folders only (not their contents, just the bin and obj folders!). Right click them, and choose Add To Igore List -> bin/obj

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. This might take some practice to get right, but it's generally straight forward.

The developer can now commit. However, before doing so, it is good practice to double check that the project still builds and that unit tests still pass after all other changes are merged.

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.