Last year the MMORPG, Eve Online, released a patch that had the potential to bugger the operating system install of any Windows user upgrading. This monumental blunder bypassed engineering and QA processes to end up in the hands of tens of thousands of unwitting consumers.

Merging is not all that difficult, but if you are doing it for the first time or you only do it infrequently, you can get a bit knotted trying to work out what you're supposed to be doing. What follows is a little crib sheet for merging. Just happens to be using Subclipse for Eclipse but the same steps apply for any Subversion client.

Recently got back from a great week away at Web On The Piste. Was talking on the topic of Code Management and implementing Subversion. I've included my slides for those that are interested. I've been trying to write up thoughts on version control and the like in the blog, so if you see anything in there that takes your fancy drop me a comment and I'll see if I've got a moment to elaborate.

It’s important to understand that Subversion is a system that records and manages file changes. It’s not a prescribed methodology for managing those files. So while Subversion provides the nuts and bolts for your version control system, you need to agree within your own team how you want to manage your code base. This can be a little overwhelming given the sophistication of Subversion and the multitude of strategies for code management it allows.

Moving to a version controlled build process requires the universal acceptance of key requirements that the development team must adhere to. If any member of the team ignores these requirements, the regime of versioning and its multitude of benefits will begin to break down.

Decentralised development means giving each developer their own workspace: the ability to code in isolation of the rest of the team, to experiment and when their happy, easily share their changes with others in the team. But the fundamental reason for moving to a distributed environment where each developer has their own private workspace is to implement version control. Without version control effective code management is impossible.

It never ceases to amaze me how many development teams work as a group from a single development server. That is, multiple developers sharing a workspace for a single application, staged on a single development server. Although this type of environment is very simple to set up, and caters wonderfully for ad hoc and sporadic development by multiple parties, it nevertheless spells disaster for more serious code management.