Configuration Management with Subversion and Google Project Hosting

CM using Subversion

It is almost impossible to build large, scalable, collaborative software systems without a (good) configuration management system. We can find evidence of this as the demand for better CM tools over time has driven the availability and adoption of more robust and easier to use CM systems. Some of these are relatively new - like Git - and are gaining popularity quickly, with the promise of speed, reliability, security, and a host of other features.

Any Configuration Management approach should address the three classic CM problems:

• The double maintenance problem (must prevent multiple copies of the same file)

• The shared data problem (must allow developers to work on the same file simultaneously)

• The simultaneous update problem (must allow the developers working on the same file to update it without clobbering each others' changes)

Subversion solves these problems by using file versioning, file checkout and commit, and resolving commit conflicts using merging. In addition there are many more features that I won't go into in this post, but I encourage you to check out on the Apache Subversion site.

For my local Subversion client, I used the Tortoise SVN client based on Subversion 1.7, which integrates seamlessly into the Windows 7 environment using context-sensitive menus. It decorates files and folders under Subversion control with easy-to-understand icons.

Using Tortoise SVN, it was very easy to put my project (source tree) under Subverion control, make my initial commit, and thereby place my project into the repository on Google project hosting. Almost immediately I realized I needed to delete some files I really didn't want in the repository, and again, this was surprisingly easy to do.

Google Project Hosting

Project Hosting using Google Code provides an easy to understand and easy to use environment for collaborative development of open source projects. It was a piece of cake to create a new project backed by Subversion for the repository. My open source project hosts my competitive Robocode robot code. It provides issue tracker, wiki pages, admin, download, and other useful pages/links on a per-project basis. I was able to document changes to the repository, view revisions/changes, add 'commit' access for project collaborators, and create both a UserGuide wiki and a DeveloperGuide wiki using the builtin editors.

I accomplished all tasks I set out to do in this first attempt at open source project hosting using a Google project hosting and a local Subversion client.

I had a few moments of misunderstanding when .svn folders were not appearing in my Tortoise SVN client. By using a shell window, I made sure they weren't there and it was not a Tortoise SVN issue. However I was able to checkout files, make changes and commits with correct expected results.

I learned from the Tortoise SVN forum (registration required to post) that Subversion 1.7 no longer maintains a .svn directory for each subdirectory of a project's files. Instead it uses a single .svn directory located at the project root. I verified this on the Apache Subversion site.

I was surprised when I was able to checkout files from the repository without supplying any credentials. I soon discovered that Google Project Hosting asks for credentials when comitting changes, not when checking out files from the repository. And Tortoise SVN can store those credentials resulting in an even quicker, more seamless workflow.