The combination of Bazaar branch hosting and Launchpad's teams infrastructure gives you a very powerful capability to collaborate on code. Essentially, you can push a branch into a shared space and anyone on that team can then commit to the branch.
This means that you can use Bazaar in the same way that you would use something like SVN, i.e. centrally hosting a branch that many people commit to. You have the added benefit, though, that anyone outside the team can always create their own personal branch of your team branch and, if they choose, upload it back to Launchpad.
However, Bazaar is flexible enough that you can choose your own workflow.
Creating your team branch
Creating a team branch works the same way as creating a personal branch: just push the branch up to your project on Launchpad.
Choosing a workflow
When you're working with a team branch, you can choose one of three workflows:
Centralised: also called lock-step, this is how Subversion and CVS work. Everyone makes commits direct to the central branch.
Centralised with local commits: similar to centralised, except that when developers are making a series of changes they use "commit --local", or unbind their checkout, then commit their work to the shared main line when it is complete.
Decentralised with shared main line: each developer has their own branch or branches, plus commit rights to the main branch. They do their work in their personal branch, then merge it into the main line when it is ready.
If you're not sure which workflow would best suit your team, there's more about Bazaar workflows in the Bazaar documentation. However, you may find that you need to experiment before you settle on one that works for your team.
Centralised (or lock-step)
A team using the centralised workflow might work something like this:
- Team members Alf, Bharat and Momoe each check out the team branch.
- Alf adds a new feature and commits his work straight back to the team branch on Launchpad.
Momoe starts work on a new feature and attempts to commit back to the team branch. Bazaar tells Momoe that her local checkout is out of date, thanks to Alf's update. So, Momoe uses bzr update to pull the latest version of the working tree from Launchpad before committing her changes back up to Launchpad.
- Bharat wants to work on an experimental idea, so creates his own personal branch of the team branch, enabling him to work separately but retaining the ability to merge back into the team branch later.
To make the initial check-out of a team branch, open a terminal and type:
$ bzr checkout lp:team-name/project-name/branch-name
Bazaar will now download just enough information to enable you to work on the code: i.e. the branch's working tree without its revision history.
When you're ready to send your work back to the branch, you commit in the usual way:
$ bzr commit -m "Enter a commit message here"
The difference here is that Bazaar pushes your commit directly back up to Launchpad, rather than making the commit to a local branch on your computer.
As we saw in the example above, it's entirely possible that someone else may have made a commit to the team branch during the time between your check-out and when you're ready to make your commit. If that's the case, Bazaar will tell you and you'll need to pull down the latest version by typing:
$ bzr update
During the update, Bazaar will merge the latest version of the branch into your local working tree. Although Bazaar has excellent support for merging, you may find some conflicts. See the section on resolving conflicts in the Bazaar user guide.
Pros and cons
Centralised with local commits
This works just like the centralised model except that each member of the team has the option of making local commits as well as committing directly to the team branch.
To make a local commit, rather than commit to the team branch, use:
$ bzr commit -m "Commit message" --local
Then commit as normal when you're ready to send your changes back to the team branch.
Pros and cons
- Allows for off-line development.
- Less chance of a bad commit affecting everyone else's work.
Decentralised with shared main line
Using this workflow, each team member developer has their own branch or branches, as well as commit rights to the team branch. They work in their personal branch, then merge it into the mainline when it is ready.
So, rather than checking out the team branch, you create your own local branch:
$ bzr branch lp:team-name/project-name/branch-name
Then, you work as normal on your local branch - making commits to it whenever you need to - and only merge with team branch when you have something that you're happy with.
Seek input on command to use. Presumably bzr merge lp:team-name/project-name/branch-name
Pros and cons
- Easier organization of work - separate changes can be developed in their own branches.
- Developers can merge one another's personal branches when working on something together.
If you're using the decentralised with shared main line workflow, or you need to merge branches for any other reasons, Launchpad's code review gives you a public and easy way to review merge proposals. Let's look at code review now.