Bloggy Hell

I know that Git is the flavour of the month in regards to version control at the moment, but I still use Subversion (SVN) for my day-to-day version control needs. And since it is still very popular, I think this quick tutorial still has it’s place. Today, I was asked by a client to show them how to branch a SVN repository so they could start making some major changes to their application with out running the risk of breaking the release version.

The scenario works something like this: You have finally launched your application and everything is purring along nicely. You decided to start working on the next iteration, which has some major changes that WILL break things initially. You start working away, and find yourself half way through the changes when you get a call from an irrate customer who can’t complete their transaction because of an obscure edge case bug that you missed. The dilemma that you have is that your source base is in a state of flux, and you can’t release it, because in it’s current state, it doesn’t work. Wouldn’t it be great if you could have maintenance version of your application that you could make the fix on? Enter branching.

Firstly, a bit of terminology. I’ve used the word “branch” a couple of times. The analogy is simple - you have a core line of code (The “trunk”) and you can have concurrent lines of code that “branch” from the trunk. One of those branches may well be our “stable” branch, meaning that the only changes that can occur are bug fixes - ie NO new features. As with any system, there is more than one way to fell a tree, but this is the system that I generally use.

So how do you do it? When I create a new SVN project, I like to add a trunk directory, and a branches directory. With in that branched directory, I add another directory called stable (let’s pretend my SVN server is at svn.myserver.com):

# Create a new project - tedious stuff like locking down access omitted for clarity
svnadmin create new_project
# Now head over to your working directory, and check out the initial version
svn co svn://svn.myserver.com/new_project
» Checked out revision 0.
cd new_project
mkdir branches
mkdir trunk
# Now to add the new directories to the repository
svn add branches trunk
» A         branches
» A         trunk
svn commit -m "Adding initial directories"
» Adding         branches
» Adding         trunk
»
» Committed revision 1.

Now we have our working copy setup and committed back to the server, you can start work on the trunk. Cut scene to the day before go live. You are pretty happy with how the trunk is looking, and you would like to branch the code into stable. For this we use the copy command

svn copy svn://svn.myserver.com/new_project/trunk svn://svn.myserver.com/new_project/branches/stable -m "Branching stable"
» Committed revision 10.
cd stable
svn update
» A    stable
» Updated to revision 11.

And we are done! Now you can continue on your merry way and change code in trunk with out affecting your stable release. Once you are happy with the next version and you’re ready to create your next stable branch from your new feature rich trunk, you can “merge” your changes from trunk into stable:

svn merge svn://svn.myserver.com/new_project/branches/stable svn://svn.myserver.com/new_project/trunk -m "Merging trunk changes into stable"
» A    new_file_that_is_in_trunk.txt

And of course it works the other way - say you found that obscure edge case bug in stable, and you have fixed it, you would want to merge the change back in to trunk, so you don’t introduce any “regression bugs” (Bugs that you fix, then inadvertently re-introduce by changing code). All you need to do is flip the order of the two URLS:

svn merge svn://svn.myserver.com/new_project/trunk svn://svn.myserver.com/new_project/branches/stable -m "Merging edge case fix from stable"
» M    fixed_file_from_stable.txt

There you go! Easy as pie - let’s just hope you don’t get to many conflicts that you need to manually resolve. It’s always a great idea to test you code again after a merge, just to be sure everything works as expected.

Put 80-odd  geeks in a room and magic happens, which is what happened on Saturday at BarCamp 2.0, Perth. It was a fantastic turn out - we even got a couple of east coasters (Thanks @marclehmann and @liako) to enjoy the frivolities. Although, due to me running around like a blowfly with it’s head cut off, I still manged to get a couple of great presentations, which could lead to some seriously cool ideas which is all you can ask from a BarCamp.

But the biggest announcement for the day was WA’s very own Web conference - Edge of the Web.  After three awesome Web Awards over the last three years, it was a natural progression for us to push the envelope a little. Keep November 6 and 7 free - it’s going to be three types of awesome. We have international and national speakers, and we are fairly good at throwing parties over this side of the Nullabor. Oh, and we are running a poll, were you can put your 3c worth in picking our logo.

Having said that. I do have one gripe about our fair city. After the PTUB that followed BarCamp at the Royal, we moved on to @richardgiles‘ place for a cuppa tea and a scone. We realised we were out of Brandy, so we went out to find a friendly establishment to purchase a night-cap or two. It was 10pm in the evening AND EVERYTHING WAS CLOSED. I seriously caught a cab out to South Perth to go through a drive through. WTF. Anyway. Enough bitching - it was a top day and night and I’m not going to let our draconian liquor licensing laws spoil that.

Anyhoo, I’m off to nurse this cold that I and half of the Perth twitterati seem to have contracted.

BarCamp Perth is but two days away, and we have nearly 90 participants, it is going to be huge. There is also something a little special that is going to make it even bigger, courtesy of Giant Dice, everyone’s favourite local pervasive gaming studio.

Introducing Silicon Breach:

In Silicon Breach, three Web 2.0 startups compete for venture capital by circulating ideas. When an idea is shared within a company, it’s good. When an idea is stolen by another company, it’s bad.

On the morning of May 10, players will be secretly assigned to a company, and they will be given a secret idea. Every idea is two words, e.g. roundedcorners or morefunding.

Noone knows your idea but you. Noone knows which company you’re in but you. You must decide how to use this information.

It sounds like a really fun game,that incorporates mystic, social engineering and rounded corners. So if you are heading to BarCamp Perth, go and register to play.