Wednesday, February 10, 2010

On Using The Wrong Tool

Subversion, as a version control system (VCS), is a mostly decent version control system. You check code in, you look at revisions, you look at logs, you can restore the state of your code at any time. It does the job it was built to do. This is not to say that it doesn't have problems, though. In fact, some of these problems have bitten me more than once. Using Subversion when other tools exist that actually correct these problems seems, to me, to be madness.
A typical setup for svn will have a repository layout that looks as follows:

repository
-branches
-tags
-trunk

I've also seen where there will be a special branch named "qa" in there. The workflow works something like this: Minor changes will checked directly into trunk. Major changes will see a copy of trunk made as a branch, and then when work is done, the branch will be merged back to trunk. If the "qa" area is in there, then the trunk will be copied to qa when a new release is ready for qa. Once the new release has vetted, it will then be copied to its own tag, and released to the world.

When a released version has an issue, and it is small enough, then some places will put the fix into that release, while others will put it into a new release. The key fact here is that it is possible for a fix to be put into a release and not copied to trunk or the optional qa branch (and, since we are only mortals, this will happen on occasion). Once the new release is cut, that fix will be lost. If svn is being used to maintain a single website, then the appearance will be that the website had a bug fixed, and then it came back for no apparent reason.

This means that somebody must now take the time to figure out what the differences are between the previous working version and the current version. Time that could be better spent on pretty much anything else.

As it turns out, a different version control system, when setup properly, handles this particular issue wonderfully (along with every other issue I've found with Subversion). The one I've used is Mercurial. It's command set is very similar to Subversion, which makes the transition extremely easy.

When you set up Mercurial to provide a similar structure to Subversion, you will have three separate repositories: devel, qa, and production. Each of them will (at the project start) be a copy of the others. When a new release is ready for qa, a tag is added, and the release is pushed to the qa repository. When that release is vetted, a tag is added, and then pushed to the production repository.


Now, assume the same thing: We have a production repository which has fixes that did not go back to qa or devel. When you try to push to production, you will receive a warning about this, since you are now creating two head revisions in the production repository. You are prompted, before any user sees the issue, to find and fix this. You wind up keeping the bug fixes. The problem goes away, and cannot come back unless you force it to come back.

Or, you can keep on futzing with Subversion, and hoping no one ever makes the mistake I've mentioned above.

And that doesn't even get into the issues of permissions, setting up the web server, dealing with patches from outside that you must now credit in log messages only (as opposed to the outside user being the one that receives the credit for the commit), none of that.

I know which one I choose and prefer.

No comments: