Slowly I’m getting around to using Subversion… It’s not yet openly available on Sourceforge (still in beta) so I’m settling on an intermediate solution. A contributor has kindly offered to host our Subversion repository from their own server. It’s been slow going but I’ll hopefully migrate from my current personal subversion server to the new public server at the weekend.

I’ve been using my home PC for that – just to get a leg up on using Subversion, before the great migration online when a stupid mistake or error on my part could inconvenience other developers.

The reason for using Subversion as opposed to CVS may not be immediately obvious. Both are very popular (CVS is still topdog AFAIK) but Subversion fixes shortcomings in CVS. The most common example, well for me anyway, is file organising. If Partholan had initially been put in CVS I would have deleted and re-initiated the repository a few times by now (which usually involves a support request on SF) – and doing so would have lost all prior version history (there’s a lot of reorganising during early development). With SVN a simple file move, or directory restructuring can be performed easily, and without losing your version histories which are useful when it comes to updated sites using older versions of say Partholan, or generating patches for select updates to a stable app.

The one thing I am looking forward to is getting rid of the development vs stable vs release problem in development. This is especially relevant for QSE where Partholan and QS development may each occur separately and require frequent merging. It also makes possible in a more intuitive way creating a separate release branch purely for freezing features and focusing entirely on stability and bug fixing, while allowing development continue undelayed in the main trunk.

This is actually a huge benefit. Something similar is possible on CVS of course but it has a more intuitive feel (so I found at least) when using Subversion. Tagging and branching actually makes more sense in SVN from the perspective of the svn novice. I remember spending a long time trying to come to grips with it in CVS so maybe I’m looking at it from a different starting point though.

Hopefully the benefits of version control will end my own bad habits in this project, and get everyone on board the stability wagon ;-). The one branch fits all approach is too easy a trap to fall into. What happens when you’re organising a stable release and developers are still making substantial feature additions and changes? Ask them to hold off for a few weeks? Not much sense in that since their time may be limited to start with, and keeping working copies out of sync for too long can be disastrous. I’m sure whoever’s overseeing the long list of conflicts that might create would not be grateful for the mess :-).

On the development site project, I’ll be adding Subversion tutorials and instructions for both Linux and Windows users (that’s the yet-to-be-fixed site over on http://www.quantum-star.com/devsite/ ). I held a small survey just for the regular public forum users (11 responses thus far) which shows users voting their predominant desktop as Linux (6) and Windows (5). Most probably use both (those pesky PC Games make sure of that) but its useful knowing what people more involved in the project are using whether developers or just those following developments.

No related posts.