pavius.net

This guide will (hopefully) enlighten you to the benefits of using a Source Control system in your development, even if you are a hobbyist working on small projects. After a 5 minute free installation you will be able to save a snapshot of your project with a single click, allowing you to modify the code knowing you can revert your changes to any state at any time.

Working as a single programmer on a project has its benefits - no one tramples your code, you can modify any module you wish at any time and as long as you keep your standards, the project will always compile. As the team grows bigger and the project becomes mission critical, many problems arise:

• Two or more programmers work on the same module - how do they share?
• Bugs in a certain version pop up that did not exist in previous, seemingly unaffected, versions. What has changed between the two versions and when?
• Customer A has received version 1, while development has reached version 20. Customer A is happy but finds a bug - do you update him to version 20 or fix this specific bug on version 1? If so, how do you find manage the source code for each customer?

Source Control, in a nutshell

Source Control systems were devised to help with the above and much much more. Commercial grade examples include cvs, svn, ClearCase, Perforce, SourceSafe and many others. They all share the same basic architecture: A single server contains a change-based repository of your projects while distributed clients (which reside on the programmers machine) allow the programmer to access code on the repository for either applying his changes to the repository (what is usually called "checking in" or "committing") or by synchronizing to the changes made to the project by others ("updating", "syncing to latest" and sometimes "checking out").

There are many guides to working with a Source Control system on the web and i won't dive into its theory of operation in a team environment. I will, however, offer a simple and free way of using Source Control in your project, even if you are a hobbyist developing stuff in your spare time.

I'm a single developer - Why should I care?

As a single developer, you gain one huge advantage of using Source Control - the ability to save the state of your project at any time, with a single click. This allows you to easily revert any changes you have made and make all manual backups of source redundant. Even if you are slightly modifying your code - and you know that the code works in its current state - save a snapshot. You will feel so confident changing the code because you know that at a click of a button you will be able to revert your changes to any previous working state.

What to install:

• The server: VisualSVN (You can use this tutorial for installation - but basically you just click next a bunch of times)
• The client: TortoiseSVN

Keep in mind that you can install both the client and server on the same machine or put the server on a different machine,. The server does not take any resources during normal operation, but it may be beneficiary to do so for safety reasons (if someone steals/hacks into/destroys your client machine, your code is still safe at the server). After installing VisualSVN, follow the tutorial above to create a repository. A repository is, in essence, just a directory that holds versions of any files you give it - it is up to you to decide how the repository looks like and how many projects (or project) it contains. Thankfully, we don't have to think too hard as there is a logical standard for this: simply create a repository per project, naming the repository after the project. When you create a repository, you are allowed the option of letting VisualSVN create a default sub structure for it. This is optional, but is recommended as this sub structure is well known and intuitive to most programmers working with SVN. This substructure contains:

• trunk: The place where ongoing development goes on. You copy your initial code here and always check your changes in to this single location. The trunk will hold the entire history of your project and will be the location you should take the source from should you want the most up to date, compiling, unstable version.
• tags: When the trunk reaches a certain milestone (say you validated all your modules), you would probably like to take a snapshot of this trunk. To do this, you simply copy it to a new sub directory in tags (effectively tagging it). For example, if your trunk version has reached version 0.2.0, create a subdirectory called 0.2.0 in tags and copy the trunk to it. You should never modify (check in) code in the tags sub folder - the whole point of a tag is to save the program's state at a given point in time.
• branches: This is a lesser used functionality and is mostly intended for larger projects with a longer lifetime and several programmers. If, for example, you would like to add a certain functionality to your source but would like this NOT to be a part of the main trunk, for whatever reason (could be that you do not want to introduce risk to the trunk, on which several programmers are working on but still would like to source control your work) - you would create a branch off of the trunk and work there. 

All of the above are not "special" sub folders and do not behave differently as far as SVN is concerned. You can choose not to follow this recommendation and find a sub structure that works for you.