Getting Started with (Sub)Version Control

Seems that, at the moment, everyone who's anyone is blogging about version control, and in particular SubVersion. So not to be out-done here is mine.

What is source control and why do I care?

The Wikipedia definition of source control or revision control on says:

"source control ... is the management of multiple revisions of the same unit of information. It is most commonly used in engineering and software development to manage ongoing development of digital documents like application source code, art resources such as blueprints or electronic models, and other projects that may be worked on by a team of people. Changes to these documents are usually identified by incrementing an associated number or letter code, termed the "revision number", "revision level", or simply "revision" and associated historically with the person making the change."

In other words it keeps track of your documents and any changes you make to them. Jeff Atwood says:

"Everyone agrees that source control is fundamental to the practice of modern software development"

and the reason everyone agrees is because having a project under source control means that you can go back to any previous version of the project or individual file and as a result of that developers and designers can make changes to the project without worrying about whether they are going to break it and not be able to get the project back to a working state.

It also makes working in a team much easier because files are no longer locked for exclusive access by 1 person, everyone has a local copy of the files, however when it comes to commit your changes back into the project repository the software can handle merging conflicts.

What do you need in order to start using Version Control

In order to implement version control for your projects you need to have, as a minimum, the following installed on your computer

• SubVersion (version 1.5 or higher is recommended)
• TortoiseSVN (version 1.5 or higher is recommended)
• VisualSVN (Optional and not free!)

TortoiseSVN integrates with the Windows shell and provides new icons to show the state of files and folders, i.e. are they new or updated.

Projects exist in a repository which is managed by the SubVersion server. Each version of the project in the repository should compile successfully, so each checkin should be for a stable version of the project. Learning the Check-in Dance can help make sure this is the case.

Workflow

To work with projects in a repository you first create a working folder on your local PC, right click the folder and select "SVN Checkout..."

Browse to the URL of the repository for the project and ensure that the Checkout directory is your working folder. When you click OK TortoiseSVN will copy the latest version of the files to your working directory. Note this only happens the first time you checkout a project after that you right click the folder and select SVN Update, this will get the latest version of the files from the repository and automatically merge any conflicts, if it cannot automatically merge it will prompt you for how to deal with the conflicts.

You then work with this local copy of the project; add files, remove files, rename or move files and folders, SVN will track all the changes for you. When you have completed your unit of work make sure that your copy builds successfully then checkout the project again, this ensures that should anyone have checked in changes since you last did that you now have the most up-to-date version of all the files. Again check that your copy builds and finally right click the folder and select SVN Commit... In the dialogue box breifly explain what changes have been made, these notes will help should we need to roll back to a previous version, your changes will be added to the repository and the version number incremented.

Ideally you should check your files in frequently (as you would save a Word document frequently), I suggest checking in after each atomic change. By only checking in small changes any bugs that arise can easily be identified and rolling back to a previous version does not wipe out other useful changes.

Useful Links

Subversion Integration for Visual Studio with Visual SVN (PDF)
Version Control wtih Subversion