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.