There has just been an announcement that the Rails-core source code version control repository is moving over from Subversion (SVN) to git and they will be using Lighthouse for bug tracking instead of trac. Does this affect you? Not directly (unless you like playing on edge-rails), but it is a good excuse to talk about source code repositories and some of the differences between subversion and git.
What’s source-code version control?
Source-code repositories provide you with a central place to store your code — they will generally do this whilst maintaining a history of your “commits” (The action of saving code back to a repository). This means that you are able to roll back code any change that you have made. If you have ever been over-zealous with the rm -rf command, you may understand why this might be handy.
Another cool feature is the ability to branch (or take a copy of) your code – this allows you to keep, say, a development and a stable version. If you find a bug that needs patching in your production version, you can merge the change back in to the development branch thus avoiding regressions bugs.
There are a number of version control systems out there, with subversion becoming one of the most popular in recent years. Recently though, git seems to be gaining some traction, especially amongst the Open Source community, because of it local repository features. In subversion, when you commit a change every other users local “working copy” had to be updated to reflect the changes, so if you were experimenting and wanted to save a version, but the changes weren’t quite ready for prime time, you were kind of stuck. Git however, allows you to keep a local repository, which doesn’t affect the public repository until you explicitly tell it to.
Many of the commands used in git are the same or similar to SVN (the names may have changed slightly), for a summary checkout this guide and if you are feeling adventurous, you can sync up a SVN branch with git using git-svn.
Myles EftosMyles a Perth-based web developer who has worked in all the major web languages, his weapon of choice being Ruby on Rails—although he’s found himself doing more and more front-end development in JavaScript, HTML, and CSS.
