I keep forgetting that we aren't all connected to the same hive mind and am surprised when friends don't know that I have left Weta (again). Everybody asks why I chose to leave, and the answer is simple. Despite the fact that I adore my job, doing it left me with very little emotional energy to do anything else. I realised that for most of my adult life, work really has been my life. For a long time that was fine because I loved my work and was happy to make it my life. However with the passing years that compromise has seemed less acceptable. With "Avatar" wrapping up, and especially now that I'm single again, it felt foolish to not take a punt and try something different.

Of course this leaves the question of what exactly is the next step, and honestly the answer is that I don't know. What I do know is I've been talking about travelling the world for longer then I can remember. As a kid, shuttling between California and New Zealand with my parents, I remember idolising the scruffy hippy kids that I'd see congregating in the corners of airports. Over the last <gulp> twenty years I've ended relationships and quit jobs to head off on this journey more times then I care to count. Yet I always allowed life to pull me back before the final plunge. The time has arrived to stare the dream square in the face and either lap in … or get over it.

What I do know is that I'll be spending the next couple months in Wellington enjoying summer and the company of friends. Then around April I'll be heading off towards Southeast Asia. My destination? The cheapest flight that gets me to Southeast Asia, I'm guessing Bangkok but hope to be surprised. From there I intend to slowly make my way westward. Since I'm not in a hurry I intend to stop for as long as I like and enjoy everything which seems worth savouring. I'll be avoiding planes and will instead travel by foot, bicycle, motorbike, boat and bus as much as possible. After exploring Southeast Asia I hope to make my way into China and from there to Tibet, down through Nepal and into India. After that I really have no idea, I suspect my initial travel companions will have headed for home by then so I'll be properly on my own. Depending on how comfortable I am in my new shoes Africa or Eastern Europe seem the most likely choices.

I've been saying that this is going to be a years trip but really I have no idea. More realistically it'll end when I: get sick of it, run out of money, find something I don't want to leave or end up back in New Zealand.

Between now and the I hope to keep the new travel section of this updated with what I learn and experience along the way.

you don't fool me not for a second i can see you have freckles
get a pencil and a surgical tool join them up and see what god made you
(see what she made you - the little slut)

and all these pictures on your skin
they bring to light your origins
they tell the world where you have bin
they tell the doctor you have sinned!

they lie in wait right down your back dirty lumps of brown & black
they may be read as diagrams stigma scars or epitaphs
i want to know if they fall out onto toilet seats or thereabouts
and if you drop some on the ground do they decompose or sit & sprout?

and all these pictures on your skin
they bring to light your origins
they tell the world what you think
they tell the doctor you can't win!

we must not let them breed in towns
but round them up in a slaughterhouse

these dirty things these signs of sin
wipe them out with paraffin
if that won't work skin them down
with a bowie knife or a body plough
so all that's left are spots of pink
mixed in with red (so pointillist)

and now your flesh is chaste redeemed
ethical and virgin clean
you've only lost some ugly freckles
(and that's shut you up you dirty rebel)

This is based on an article which Noah and I wrote for IBM developerWorks. Unfortunately that version (published in April 2009) included some significant mistakes. This is my attempt to improve upon the original, any new errors introduced in this version are purely my responsibility.

Learn about and compare how to use Bazaar, Mercurial, and Git
By Adam Shand & Noah Gift

Summary: Interested in distributed version control but intimidated by all the jargon? This article provides an introduction to the three main systems available (Git, Mercurial, and Bazaar), discusses some of the advantages gained from adopting a distributed workflow, and provides a quick start guide for each of the three systems.

Introduction

Over the last few years there has been much discussion about the benefits distributed version control systems (DVCS) can offer your development process. Distributed tools have now matured to the point where there are few downsides remaining. While some of the advantages may not be initially compelling, the extra flexibility that distributed tools provide makes a lot of sense in the long run. By the end of this article you should know enough to get started with a distributed version control system and have a basic understanding of the advantages a distributed model can provide.

Much of the discussion around distributed version control has focused on a central server no longer being required. While this is a distinguishing feature, and vital to some groups of developers, the real value is that it allows groups of developers to implement nearly any workflow that they choose. The possibilities range from two developers sharing changes with no infrastructure other then a shared wireless network to the traditional centralised model.

This enablement of different ways for people to work is what is truly exciting about distributed version control. The end of the article provides a how to guide for a simple ad hoc workflow which could be used by writers, school teachers or hard-core Linux kernel developers.

What is distributed version control?

Distributed version control system is a way to manage many versions of files on many different computers without requiring a centralised server. Collections of changes can be exchanged with other users to allow easy merging of changes.

The main advantage is that it is provides a lot of flexibility when it comes to designing your version control workflows. In addition, because it requires a full copy of the repository to exist on the client, it is very fast to perform most operations and it can be effectively used without a network connection.

Distributed version control workflows

Because distributed version control is so flexible, there are a vast number of potential workflows. One common workflow is an ad hoc workflow. Using this a developer starts a project and makes a branch which they want to share. They then push changes back and forth between branches that another developer is working on, and merge those changes in each time.

Another common workflow is to use a centralised server with local commits. Using this a developer works similarly to how they would with a Subversion repository, except they commit locally, and then push a final change to the centralised server. There are many variations to this, including intermixing the ad hoc workflow with. The main thing to take away is that there are many ways to work, and distributed version control provides the flexibility to choose which way works best for you.

Quick start guide

One of the best ways to actually understand a new technology is to work with it. In this next section, you can walk through the article while it runs through common operations in Mercurial, Bazaar, and Git:

Mercurial

• Install: sudo easy_install mercurial
• Make project directory: mkdir hgrepo; cd hgrepo
• Initialise project: hg init
• Add a file: touch foo.txt; hg add foo.txt
• Commit: hg commit -m "added foo.txt"
• Grab shared repository: hg clone ssh://example.com//projects/hgrepo
• Push changes to server: hg push
• See pending updates as patches: hg incoming -p
• Download updates from server: hg pull
• Apply changes: hg update
• Merge conflicts: hg merge
• Merge two unrelated remote repositories: hg pull -f ssh://example2.com//projects/hgrepo

Bazaar

• Install: sudo easy_install bzr
• Make project directory: mkdir bzrrepo; cd bzrrepo
• Initialise project: bzr init
• Add a file: touch foo.txt; bzr add foo.txt
• Commit: bzr commit -m "added foo.txt"
• Grab shared repository: bzr branch bzr+ssh://example.com/projects/gitrepo
• Push changes to server: bzr push
• Download updates from server: bzr pull
• Apply changes: bzr update
• Merge conflicts: bzr merge

Git

• Install: Download the latest tar file
• Make project directory: mkdir gitrepo; cd gitrepo
• Initialise project: git init
• Add a file: touch foo.txt; git add foo.txt
• Commit: git commit -m "added foo.txt"
• Grab shared repository: git clone ssh://example.com/projects/bzrrepo
• Push changes to server: git push
• Download updates from server: git pull
• Merge conflicts: git merge

Conversion tools and integration with Subversion

All three systems have the ability to integrate with existing Subversion repositories, they also provide varying degrees of integration with other distributed systems. There is a standalone tool called tailor which allows you to convert repository to another format (eg. Git to Mercurial or Subversion to Bazaar).

These tools make experimenting with distributed systems a straight forward process and greatly simplify migrating between systems should the need arise.

Third party hosting options

If you don't want to host your own server, there are some popular choices for hosting your project with Git, Bazaar, or Mercurial.

For Mercurial, a popular free and paid hosting site is Bitbucket. For Git, there is a similar service called Github, and for Bazaar there is Launchpad. In addition to these specific services SourceForge provides support for all three (plus Subversion and CVS) and Google Code supports Mercurial in addition to Subversion.

Example ad hoc workflow using Mercurial

An example of when a simple ad hoc workflow might be useful is if you are working with a friend in a coffee shop. In this instance the only infrastructure you have available might be your two laptops plus a local wireless network.

Here's an example of how you and your friend can easily and securely exchange code using Mercurial and the above resources.

You create a repository using Mercurial:

mkdir /tmp/myhgrepo
cd /tmp/myhgrepo
hg init

When you are ready you use Mercurial's built in web server to share a read only version of your new repository:

hg serve

Your friend can then make a copy of your repository by using the clone command:

hg clone http://192.168.1.2:8000

Your friend is now free to make any changes to their local copy of the repository. When they are ready they also share a read only version of their repository:

hg serve

You can then pull down changes that your friend has made whenever it suits:

hg pull http://192.168.1.3:8000

With this workflow yet each developer is secure in knowing that they are only changing their local copy of the files, and yet it still provides a simple way to send and receive changes between the developers.

Hint: If you are both using Mac's there's a convenient trick. Instead of using each other's IP addresses you can use each other's Bonjour name. Every Mac computer is reachable on the local network by appending ".local" to their hostname. So if your partners Mac is called maus you could use the below command:

hg clone http://maus.local:8000

Conclusion

This article explains the benefits of distributed version control and some of the differences between the three main options. If you are new to version control, continue to experiment and learn about hooks and plugins and the power that they provide.

If you are an old hand, then you should be up to speed with each of the tools so you can use them to their best advantage. Review the links in the resources section, which contain more detailed information on the specifics of distributed version control and how some people are using it.

Resources

• BetterExplained's illustrated introduction to distributed version control.
• InfoQ's "Not-So-Quick Guide" to distributed version control.
• Wikipedia's overview on distributed version control.
• Google's analysis of why they chose Mercurial.
• Tailor is an "anything" to "anything" version control migration tool.
• "The Definitive Guide" to Mercurial.
• Mercurial provides hgsvn and Hg-Git for working with remote Subversion and Git repositories.
• Git provides git-svn for working with remote Subversion repositories.
• Bazaar provides a variety of options for working with remote Subversion or Git repositories.