Bazaar

Bazaar

 




Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Bazaar supports many different kinds of workflow, rather than insisting that you work in one way only. In Bazaar there isn't exactly One True Way: it can adapt to what is best for your codebase and team.

Solo

Whether developing software, editing documents or changing configuration files, having an easy-to-use VCS tool can help. A single user can use this workflow effectively for managing projects where they are the only contributor.

attachment:workflows_single.png

Advantages over not using version control at all:

  • backup of old versions
  • rollback to an earlier state
  • tracking of history

The key features of Bazaar appropriate for this workflow are low administration (no server setup) and ease of use.

For more information please read Bazaar in five minutes or the Personal version control section of the Bazaar User Guide.

Partner

Sometimes two people need to work together sharing changes as they go. This commonly starts off as a Solo workflow (see above) or a team-oriented workflow (see below). At some point, the second person takes a branch (copy including history) of what the first person has done. They can then work in parallel exchanging changes by merging when appropriate.

attachment:workflows_peer.png

Advantages over Solo are:

  • easier sharing of changes
  • each line of each text file can be attributed to a particular change including who changed it, when and why.

When implementing this workflow, Bazaar's advantages over CVS and Subversion include:

  • no server to setup
  • intelligent merging means merging multiple times isn't painful.

For more information please read Sharing with peers section of the Bazaar User Guide.

Centralized

Also known as lock-step. This is essentially the same as the workflow encouraged/enforced by CVS and Subversion. All developers work on the same branch (or branches). They run "bzr update" to get their checkout up-to-date, then "bzr commit" to commit.

attachment:workflows_centralized.png

Subversion and CVS are good choices for implementing this workflow because they make it easy. Unlike the vast majority of distributed VCS tools, Bazaar makes it easy as well by directly supporting it. In addition, Bazaar provides some important advantages over CVS and Subversion:

  • much better branching and merging
  • better re-naming support.

For more information please read Team collaboration, central style section of the Bazaar User Guide.

Centralized with local commits

This is essentially the same as the Centralized model, except that when developers are making a series of changes, they do "commit --local" or unbind their checkout, then commit their work to the shared mainline when it is complete.

attachment:workflows_localcommit.png

Advantages over Centralized:

  • Can work offline, e.g. when disconnected during travel
  • Less chance for a bad commit to interfere with everyone else's work

Subversion and CVS do not support this model. Other distributed VCS tools can support it, but do so less directly than Bazaar does.

Decentralized with shared mainline

In this workflow, 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 mainline when it is ready.

attachment:workflows_shared.png

Advantage over Centralized with local commits:

  • 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

Subversion and CVS do not support this model. Other distributed VCS tools support it. When selecting a DVCS tool for this workflow, look for ease of use, high quality merging, good renaming support and efficient storage (e.g. shared repositories), all of which are strengths of Bazaar.

For more information please read Team collaboration, distributed style section of the Bazaar User Guide.

Decentralized with human gatekeeper

In this workflow, each developer has their own branch or branches, plus read-only access to the main branch. One developer (the gatekeeper) has commit rights to the main branch. When a developer wants their work merged, they ask the gatekeeper to merge it. The gatekeeper does code review, and merges the work into the main branch if it meets the necessary standards.

attachment:workflows_gatekeeper.png

Advantage over Decentralized with shared mainline:

  • Code is always reviewed before it enters the mainline.

A companion tool of Bazaar's called Bundle Buggy can be very useful for tracking what changes are up for review, their status and reviewer comments. Subversion and CVS do not support this model. Other distributed VCS tools can support it. When selecting a DVCS tool for this workflow, once again look for ease of use, high quality merging, good renaming support and efficient storage.

Decentralized with automatic gatekeeper

In this workflow, each developer has their own branch or branches, plus read-only access to the mainline. A software gatekeeper (e.g. PQM) has commit rights to the main branch. When a developer wants their work merged, they request another person to review it. Once passed review, either the original author or the reviewer asks the gatekeeper to merge it, depending on team policies. The gatekeeper does a merge, a compile, and runs the test suite. If the code passes, it is merged into the mainline.

Note: As an alternative, the review step can be skipped and the author can submit the change to the automatic gatekeeper without it. (This is particularly appropriate when using practices such as Pair Programming that effectively promote just-in-time reviews instead of reviewing code as a separate step.)

attachment:workflows_pqm.png

Advantages over Decentralized with human gatekeeper:

  • Code is always tested before it enters the mainline (so the integrity of the mainline is higher)
  • Scales better as teams grow.

A companion tool of Bazaar's called Patch Queue Manager (PQM) can provide the automated gatekeeper capability. Otherwise, the comments on tool selection given for Decentralized with human gatekeeper apply here as well.

Notes

One of the great things about Bazaar is its adaptability to different ways of working. Workflows can be changed, mixed and matched as required. For example, a team may decide to use the traditional Centralized workflow but supplement it with Partner, i.e. two developers might exchange changes directly when working closely together.

Workflows are mostly separate from data-storage concerns. If you want to make sure all branches are stored in a central location, there are ways to do that, e.g. by pushing changes to a central server that is backed up. In many teams using a central VCS tool, developers are known to make commits just so code is backed-up and check-pointed in case they wish to go back to that state of the code. With a DVCS, these goals can still be met without committing code into the mainline before it should be.

The Bazaar developers use Decentralized with automatic gatekeeper (using Bundle Buggy for reviewing and PQM as the gatekeeper) to develop Bazaar itself.

The images above, in both PNG and SVG format, are available as attachments to this page.

This page in other languages