Look alive. Here comes a buzzard.

I’d like to take a few moments for some shameless self promotion.  Yesterday I was happy to release Sublime 1.0.  Sublime is a Subversion management application designed for Microsoft-centric environments.

Subversion is an excellent SCM tool – arguably the leading SCM tool available today. But with its roots firmly in the open source / linux community, there aren’t a lot of Windows-based applications for managing subversion.  Tools like VisualSVN server make it easy to install and configure Subversion, but it requires access to the server for management.  Web-based Subversion apps can be found, but they are often built in PHP and may not fit with a “Microsoft Shop’s” IT strategy.

Sublime was designed for exactly these reasons.  Sublime provides a web-based management tool for your Subversion infrastructure.  It allows users to browse and create repositories, manage permissions, and enable email alerts all from a simple web interface.  Server administrators can configure automated backups, manage users and groups, and monitor server health all from a web browser.  The Sublime installer will automatically install Subversion if required making the setup process extremely fast and simple.

Ultimately, Sublime makes it easy for dev teams to use Subversion without any bottlenecks.  Users don’t have to wait for IT to create repositories, users can manage their own password, repository owners can manage permissions, etc.  At the same time, IT has the ability to manage the server and ensure data is backed up all within a Windows-based environment they are familiar with.  Everybody’s happy

I’m super excited about this release.  If you use Subversion today, or are thinking of moving to Subversion from a different SCM tool (or *gasp* no SCM tool), then I would encourage you to take a look at the Sublime website for more information.

Okay.  Plug over.  We now return you to your regularly scheduled blog.

It struck me the other day that the way I use source control is very similar to how I play video games – specifically, when and how I save my game.  I like to use source control as a safety net – it’s a way to keep track of a place I may need to return to.  It allows me to continue on with my work and not be worried if I go down a wrong path.  I can always revert and be right back where I started.

Taking this one step further, we might say that the quick save in a video game is like a commit in source control. Saving your game with a specific name is like creating a branch.

Let’s say I just finish taking out a whole horde of zombies (Left 4 Dead anticipation is infiltrating my blog).  I’ll probably do a quick-save to make sure I don’t have to re-play the same encounter again.  This is just like committing some code you just finished.  You’re saving your current progress to make sure you don’t have to re-write the same code twice.

Now, back to my game, what if I come to a fork in the road.  I can go left through the ominous looking sewer, or I can go right through the abandoned city.  Well at this point I’ll go and save my game with some sort of name like “Taking the sewer”.  That way I can continue playing, quick-saving as I go, but I can always get back to that fork if it turns out I made a mistake.

This is very similar to creating a branch in source control. You want to start working on something new, or something experimental, and you need to be able to save your progress as you go, but you always may need to go back to that original point.

I find that many developers wait too long to commit their changes.  The more frequently you commit, and the more organized you are about it, the less you have to worry about keeping track of every change you make.  This means you have left cruft floating around in your mind to remember and you can concentrate on writing good code.  I think if developers think about source control the same way they think about saving their game progress, it would help them get into the habit of committing frequently and branching appropriately.