SVN - Subversion

This is meant as a quick start guide to using available Subversion tools.

Remember, for now we just need to be figuring out a reliable work-flow process. So if you plan on doing any coding, get involved now and help sort things out. Use your best judgment with all of this, but do not allow yourself to skip the often neglected step of documenting what you are doing! It is almost as critical as commenting your code. Remember that the end goal to all of this is to make sure everyone is on the same page throughout the development process. At the same time, we need to make sure we are not creating too much overhead or frustration for ourselves. Keep this in mind.

Subversion Clients

Add to this list as you find tools that you prefer to use

Below is a list of the clients that have been tested to work with our setup as well as information to help you choose and configure specific clients.

TortoiseSVN - tortoiseSVN Detailed guide
This is a Subversion client that adds itself right into the Windows shell. Meaning you get access to the tool by right clicking the directory you are working with from Windows File Manger(Explorer) rather than through an active application or plugin. You can download the latest version of TortoiseSVN from their downloads page.

Quick Start

1. First, download and install the client you are going to use.

See above list.

As a note, the AnkhSVN FAQ page claims Microsoft doesn't officially allow 3rd party tools to integrate with the Express environments… which might explain the seeming lack of free Express friendly solutions(which would be ideal).

2. Do an SVN Checkout of the remote repository.

The first step is to define the remote location and provide login credentials to the repository you are connecting to and get the code contained there. We currently are using Google Code to host our project, so the URL of our repository is (NOTE:: if you append /source to this URL, you can set the source folder to be the root folder for your local copy of the project - meaning you can focus on what you need to get at a little bit easier). Your username is what you use to login to Google Code with and your password is a random string located on your Google Code profile page(which can be pulled up from the source tab when logged in to the project).

3. Update each time before you begin working.

This is absolutely critical to making any of this of very useful. If you fail to update before you begin working on a project, there is a chance you will be redoing something that somebody else has already done or introducing some funky bugs if you tried fixing something that no longer needed to be fixed. While there is a merge capability with subversion, it is far easier and safer to just keep you local files up to date each time you sit down to code anything or even look over the code for that matter. This is what versioning software does for you. It provides a way to keep all users up to date with the most current code regardless of everyone's physical proximity to each other. But, this is the key here, it only works if you use it.

4. Commit your changes and PLEASE comment what you did!

If you don't commit your code, we will never see your changes and you will never really be participating with the coding process. Adding details here is quite useful for those times that things get a bit muddled, so include things like what was your purpose with making the change, what changes were actually made and what might still need to be done along with each commit. It is a good idea to try and keep your commits to a minimum. Meaning that we all need to make sure the changes being put through are well thought out and needed so that we don't racking up our revision number by doing one-sy two-sy updates or "unfixing" things. It can get a lot more complicated if we ever have to rollback our code if we are all committing our code too often. The same problem exists if we aren't doing our commits frequently enough too because then we are missing key steps and have to make huge jumps.

A good rule of thumb is if you need your change to be included in the project, commit it. Always. If you find it is not worth witting some documentation for the change and detailing what it did, go back and look at why it is needed - then document it anyways. And don't forget to commit if you find it really is needed.

The end goal here is a reliable system that allows us to go back to any point and see what was done and why, Not to be a source of frustration. This all seems to work out the best with a combination of a public documentation system that all developers actively contribute to and the subversion commit comments. This combination of issue based documentation and the actual commit comments give us most all of the information needed to paint a pretty good picture of what was going on when even when the coder who produced the change is unavailable for comment. In short, documentation coupled with a good, well used version control package provides a mechanism to push the development process forward in a way that makes it easier for all team members to know what is going on at all times. (not quite sure yet on all of the details of what is going to be the best solution here, but some combination of an issue tracking system combined with the commit comments seems to be the most logical solution. For now, we should probably just use what looks to be the best mix and we can iron out the details as we go along).

If you find this document left out any important concepts, or if didn't explain things clearly enough for you(especially new users to versioning tools), please make suggestions and/or updates to this page. If you prefer a specific tool over another, go ahead and create a page detailing how to use it - everything from its configuration to the pros and cons of daily use of the tool so we can all benefit from your experiences. Be sure to add it to the list above as well as creating a wiki page for the tool so that others can easily find it. If it is not a free solution, or if it doesn't work with with VS 2005 C# Express Edition, please include a note informing us of either of these limitations.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License