Since I'm the sole programmer on my own personal game engine, I didn't feel much pressure in using configuration management software. I had at one point been reliant on regular backups by simply zipping the entire solution directory and timestamping the zip file. I keep a changelog that summarizes the changes made to the code base in order to hint at the state of the code snapshot in case I ever needed to roll back to that version. I've was never thrilled with solution; 95% (buttpull number) of each zip contained code that had not changed, rolling back could result in lots of snooping around to find the correct version, the backup process was time consuming, no diff mechanism to verify that I actually wanted to keep all changes made for this version snapshot.

A while back, I found a good opportunity to switch over to subversion for all of my revision needs. I had setup a svn repository on a remote ubuntu server in the past, but I hardly keep that old clunker running so it was a pain to power up a machine each time I wanted to check in some code. My newer approach was to create a repository on my development laptop and check in code locally. The plan is regularly backup this repository onto another machine for redundancy purposes. Since the repository is stored on my local development machine, I know it will always be online for code checkins. If the machine happens to be powered down, I certainly won't be coding.

To setup this standalone svn repository, I used Tortoise SVN (http://tortoisesvn.tigris.org/). This was the only download needed. After installing and rebooting, I created my repository by creating a folder named "svn_repository", right clicking on that new folder, and selecting TortoiseSVN->"Create Repository Here".

The next step required is setup the structure of the svn repository. I prefer to use the trunk, braches, tags structure for my repository. To do this, I created a temporary directory (C:\svn_temp) and placed three empty subfolders here, svn_temp\trunk, svn_temp\branches, and svn_temp\tags. Right click on svn_temp and select "Tortoise SVN -> Import ...". For the comment, I just said something along the lines of "Repository folder structure". The URL of the repository in my case was "file:///c:/projects/svn_repository", which was the top directory for my repository.

The final step involves the importing of my current code base. Since the trunk is the active (and sometimes unstable) HEAD of the repository, I wanted to import my first batch of code into the trunk. I didn't see this code base as being at any major version, so that is why I chose a checkin into the trunk rather than the tags directory. First I created a directory called svn_workingcopies. I right clicked on this new folder and selected Checkout. For the repository URL, I specified ""file:///c:/projects/svn_repository/trunk", since I was planning on working on the trunk. The operation should complete successfully, and there won't be any new contents added to this svn_workingcopies directory since the trunk is currently empty. I copied and pasted my entire code base from the old location (that was archived with zip files), to the new svn_workingcopies directory. To add this codebase to svn, I right clicked on the top level directory of my newly copied project ("c:\projects\svn_workingcopies\azrial") and selected "Tortoise SVN -> Add". From here I weeded out (unchecked) any file that was generated (game log files, Debug directory contents, Release Directory contents, etc). I didn't want stuff in the repository that would change each time I ran my project. Now that everything is added, it is ready to be committed to the repository. This was done by right clicking on the project and selecting "SVN Commit". After double checking that I was checking in only the essential files, I hit ok and was left with a full code base in the trunk directory of my repository.

With all of this in place, I will be creating tags at major code milestones, creating branches when I plan to do some experimentation on the codebase, and performing diffs on files before doing commits to verify that no "test code" sneaks into the repository.