The Bazaar version control system is very powerful. It is a distributed version control system, which means it’s de-centralised. Older systems like SVN were a centralised system, where there was only one place to commit changes – the central distribution server.
Using distributed version control effectively does make your life easier to when developing. It allows parallel programming tasks to be performed much more easily than was previously possible whilst also allowing all of the parallel programming tasks to have their own version control.
Using Bazaar like SVN
Bazaar includes the facilities to act like a centralised server, and has commands that mimic SVN-esque tasks. For example, in this way of thinking we can go ahead and use the same commands as we would do with SVN. Let’s step through making a change to one of the valvers projects now, working on a single change – this normally paradime’s a bug fix or similar:
Checkout the central codebase
First, we do a checkout to get a copy of the central code (i.e. the development trunk). On the command line we do:
bzr checkout lp:valvers-
This creates a new directory with a copy of the latest code in. Important: This directory checkout is tied to the central repository. We may make changes to the code, but we can’t commit unless we have access to the central repository. This is an important reason for moving to distributed version control, as we will see in a bit.
We are editing a bug, so go ahead and edit one of the files source file. If we at this point now decide to work on something else before we can get this bugfix tested, we are a bit stuck. We cannot commit this change locally, because of the directories link to the central repository. So we’re stuck with making more changes on-top. In the end, we are in the situation where we might as well not have source control. Every commit we make goes to the central repository, but this is not what we want. We want to include our changes in the central repository only after a bug fix is complete and any test cases have been fulfilled, along with any added documentation.
We also want our commits to be succinct. A commit should include the bug fix, test-case changes, and documentation changes that are relevant to the bug-fix only. The commit should not be contaminated with other changes that we happened to be working on at the same time.
We’ve typed in one command, edited one file and we can already see a weakness with this way of working. Distributed version control is the answer to working effectively on parallel parts of a project in a succinct and logical manner.
Distributed Version Control with Bazaar
So the answer is to use Bazaar as a distributed version control system.
Lets look at the same example, but approach it from a slightly different angle. We first need a copy of the code we want to start working with. Again, this is the master copy of the trunk code (or the branch you are wanting to modify). We issue the slightly different Bazaar command line:
bzr branch lp:valvers-
This again creates a new folder which contains a copy of the latest trunk code. The difference here is that the directory is now a bzr standalone branch. This means that it is not linked to the original trunk code. It becomes detached, and can be committed to like a central repository. The changes will not be immediately sent to the central server because there is no link. Even offline, we can commit to this branch as many times as we like whilst we fix a bug or develop a feature:
bzr commit -m "Started a fix for bug #lp:81231234"
etc. will only update locally to this branch. We can then later create a patch to update the central repository with by again using bazaar (there’s no need for a separate diff utility):
bzr diff >> changes.diff
We are in trouble here though, other people having been committing to the master copy and now we’ve introduced conflicts that would need resolving…