Bazaar Workflow

[Stephen J. Turnbull]

Daed Lee writes:

 > Mercurial prevents you from merging with uncommitted changes in your
 > local working copy.

All distributed revision control systems will do that.  This is a
GoodThang[tm].  As David mentions, git provides some extra
flexibility, but most people 'round hereabouts seem to consider that
to be the flexibility of a noose.<wink>

 > The workaround is to keep two clones locally, one for your actual
 > work, and another for syncing with the master repository.

Yeah, that workflow is not for me.  While I'm currently using git, so
haven't tried either in production myself, let me suggest that Bazaar
provides two functions.  The easy one is "shelve" (like "git stash",
see the "interrupted fix workflow" example in PEP 374:
http://www.python.org/dev/peps/pep-0374/#separation-of-issue-dependencies),
which allows you to "shelve" your current work, "do some other work --
including VCS operations", then "unshelve" to get back to where you
were.  I believe it provides the flexibility to apply the shelved
changes to the merged revision.

The more invasive change to your workflow would be to use a loom (a la
Mercurial queues or Stacked Git).  Although I gather they provide far
more power than this, you could think of them as "named shelves" for
the present purpose.  An example of how to use looms is as above, same
URL, same fragment.  The FLUFL (aka Barry Warsaw, who wrote the bzr
examples in the PEP) has been known to break into song just thinking
about looms. :-)

Shelve is builtin, loom is a plugin but I believe it's distributed
with the bzr core.