Bazaar

Bazaar

 




Wiki Tools

  • Find Page
  • Recent Changes
  • Page History
  • Attachments

Revision 1 as of 2009-02-23 11:53:42

Clear message

Summary

Bazaar is a very flexible tool but that flexibility translates to complexity for new users trying to get started contributing to a project. Shared repositories, lightweight checkouts, bound branches and trees vs no-trees are sweet but its too much for a new user to digest. We need an easier way for users to bootstrap into a local workspace setup appropriate for the project's size & workflows and the user's planned contribution level.

Background

The best way for a Bazaar user to organise their workspace for a project depends on numerous factors including:

  • user role: project owner vs core developer vs casual contributor
  • workflows: particularly the workflow the project encourages/mandates for making contributions
  • size: large projects have different resource requirements to small ones.

There are at least 4 common ways of organising one's workspace. For want of better names, let's call them:

  • lightweight checkout
  • standalone branch
  • feature branches
  • switchable sandbox.

A brief description of each follows.

Lightweight checkout

In this model, the working tree is local and the branch is remote. This is the standard model used by CVS and Subversion: it's simple and well understood.

To setup:

  bzr checkout --lightweight URL [my-dir]
  cd my-dir

To work:

  (make changes)
  bzr commit
  (make changes)
  bzr commit

Note that each commit implicitly publishes the change to everyone else working from that branch.

Standalone branch

In this model, the working tree, branch and repository are all in the one place. This is the "default" model of Bazaar and Mercurial.

To setup:

  bzr branch URL [my-dir]
  cd mydir

To work:

  (make changes)
  bzr commit
  (make changes)
  bzr commit

To publish changes to a central location:

  bzr push [URL]

Feature branches

In this model, there are multiple branches/trees, typically sharing a repository. One branch is kept as a mirror of "upstream" and each unit-of-work (i.e. bug-fix or enhancement) gets it's own "feature" branch. This model is recommended by many DVCS users as the best way of working for most moderately-sized projects.

To setup:

  bzr init-repo project
  cd project
  bzr branch URL trunk

To start a feature branch:

  bzr branch trunk featureX
  cd featureX

As a variation, the trunk can be created as a checkout.

Local sandbox

The git model ...

To setup:

  bzr init-repo --no-trees project
  cd project
  bzr branch URL trunk
  bzr checkout --lightweight trunk sandbox
  cd sandbox

To start a feature branch:

  bzr branch ../trunk ../featureX
  bzr switch ../featureX

Proposed UI

To do ...