Migrating From SVN to BZR Without Pain<br />
======================================<br />
Although SVN has cheap copies for branching, some dev teams find it quite hard to manage merges and so rather than using many different branches for different purposes they use "lockstep" development with everyone working on the trunk at all times.<br />
<br />
Distributed revision control systems such as Bazaar work on quite a different paradigm, so moving a development team from SVN to BZR can involve radical changes to the thought processes and workflow of the team. The trick to an SVN to BZR migration is getting over the first step: getting all your developers using BZR in place of SVN, even if they are not making full use of its power. To make the transition as painless as possible it's often best to deploy BZR so that it mimics your SVN workflow, at least initially, and get everyone accustomed to typing "bzr commit" instead of "svn commit". Once they are comfortable with using bzr commands as direct replacements for the equivalent svn commands you can then take the next step and introduce a more flexible workflow to take advantage of the power of BZR.<br />
<br />
** Step 1: Direct Replacement **<br />
The typical workflow of Subversion uses a central repository with each developer checking out a working copy. Updates are pulled straight from the repo, and all commits go straight back to it. No commits are stored locally.<br />
<br />
Start by creating a central repository on a machine that all your developers have SSH access to:<br />
<br />
  bzr init-repo --no-trees MyRepo<br />
<br />
Create a group for your developers:<br />
<br />
  groupadd developers<br />
<br />
Put your developers in that group:<br />
<br />
  useradd dev1 developers<br />
  useradd dev2 developers<br />
    ...etc<br />
<br />
Set the ownership and privileges on the repo:<br />
<br />
  chgrp -R developers MyRepo<br />
  chmod -R g+w MyRepo<br />
<br />
Set the "sticky" bit to ensure group ownership is maintained:<br />
<br />
  chmod -R g+t MyRepo<br />
<br />
Populate the repo with the trunk as a starting point:<br />
<br />
  bzr init WorkingCopy<br />
  cd WorkingCopy<br />
  mkdir trunk<br />
  bzr add trunk<br />
  bzr commit -m "Created trunk"<br />
  bzr push bzr+ssh://dev1@repohost.example.com/home/repo/MyRepo/trunk<br />
<br />
That will create a branch called "trunk" (!) in the repository.<br />
<br />
Your developers can now check out the trunk from the repo:<br />
<br />
  bzr checkout bzr+ssh://dev2@repohost.example.com/home/repo/MyRepo/trunk WorkingCopy2<br />
<br />
They can then work within their working copy, and it will behave just like a Subversion checkout. They can grab the latest changes from the repo with:<br />
<br />
  bzr update<br />
<br />
And when they make their own changes, they can commit them straight back to the repo with:<br />
<br />
  bzr commit<br />
<br />
In other words, it works just like your old SVN workflow - but with BZR as the underlying mechanism. Let your developers use it that way for a while, retraining their muscle-memory to type "bzr" in place of "svn". Hopefully they'll barely even notice and everything will run as smoothly as before, but now you're in a great position to take the next step and begin making use of some of the additional flexibility of BZR.<br />
<br />
** Step 2: Personal Branches **<br />
One of the powerful aspects of BZR is its ability to manage and visualise a large number of branches, allowing you to move to a workflow that involves creating new branches for even small changes such as bug fixes or minor features. Once your developers are happy working with bzr, move them all to working on a single personal branch each: instead of working directly in their mainline checkout, have them branch it and work in the branch. This can be as simple as:<br />
<br />
  bzr branch WorkingCopy MyPersonalBranch<br />
<br />
to create the branch. Then when they make changes in their branch, their commits will remain local: "bzr commit" in the branch commits to the branch, not to the repo. They can therefore commit often safe in the knowledge that they are not breaking the mainline for any other developer.<br />
<br />
To update their branch with changes from the repo they then need to do a two-step process: update their checked-out working copy from the repo, then pull those changes into the branch:<br />
<br />
  cd WorkingCopy<br />
  bzr update<br />
  cd ../MyPersonalBranch<br />
  bzr pull ../WorkingCopy<br />
<br />
After the first time they do "pull" they don't need to specify the source path for the "bzr pull" command, because it will be cached locally.<br />
<br />
The changes they make in their personal branch are likewise sent back up to the repo in two steps. The first step merges their changes from the branch to their working copy, and the second commits those changes back to the master branch in the repo:<br />
<br />
  cd WorkingCopy<br />
  bzr merge ../MyPersonalBranch<br />
  bzr commit<br />
<br />
** Step 3: Branches For Everything **<br />
Once your developers are accustomed to a workflow that uses a local working copy and a personal branch to isolate their commits from the repository, it's a small step to encourage them to create new branches for specific purposes instead of re-using a single personal branch for everything.<br />
...<br />
...