Maintaining multi-layered, interdependent branches

[Robert Collins]

On Sat, 2009-01-10 at 12:10 +1100, Ben Finney wrote:
> Howdy all,
> 
> The “loom” feature seems targeted at maintaining multiple branches
> from some starting point, where the branches have complex dependency
> relationships. Which is good, because that's what I want to do.
> 
> The only documentation I can find, though, is the ‘bzr help loom’
> command summary, which assumes I know how looms work, and the
> <URL:http://bazaar-vcs.org/Documentation/LoomAsSmarterQuilt> page,
> which assumes I know the workflow of ‘quilt’.

README and HOWTO contain more information -
http://bazaar.launchpad.net/%7Ebzr-loom-devs/bzr-loom/trunk/files/

> I know neither, so I'm quite confused.
> 
> 
> Here's a use case: Arthur is developing various branches against an
> upstream, Bernard, who is only sporadic in responding to Arthur's
> patches. He has the following branches to maintain:
> 
>     upstream-checkout
>     bugfix-foo
>     feature-wibble (depends on bugfix-foo)
>     feature-wobble (depends on bugfix-foo)
>     bugfix-bar (depends on feature-wobble)
>     bugfix-baz
>     feature-warble (depends on feature-wobble and bugfix-baz)
>     feature-weeble (depends on bugfix-bar)
> 
> While Arthur is developing, Bernard intermittently announces new
> revisions, so Arthur must also update his ‘upstream’ checkout. Arthur
> isn't sure whether the dependencies among his local branches will
> change over time, or which ones will be good for submitting back to
> Bernard in what order.
> 
> 
> Questions in no sensible order:
> 
> What is the proposed workflow for Arthur?

Generally, hack on a feature. To pull new code from Bernard, shelve any
current uncommitted changes, switch upstream-checkout, bzr pull, bzr
up-thread --auto top:, rinse and repeat

> How should Arthur set up his repositories, branches, looms, and
> threads?

arthur doesn't need a repository, needs one branch - which is his loom.
the first thread should be the upstream, and above that his features in
any topo sorted order. 

> What does Arthur need to do to move from a “separate branch per line
> of development” model, to one where looms and threads are involved?

It may be more convenient. In particular the whole group of branches can
be versioned (which is more relevant to distribution packaging workflow,
where multiple distributions have a set of features which are released
as a group per-distro.

> What changes in workflow are required? What new things should Arthur
> be doing while he develops the branches? What existing practices
> should he not be doing?

Arthur should 'bzr record' his loom before pushing it. I don't know what
Arthur does today, so I can't comment on what not to do.

> What procedure should Arthur follow to send changes from his work to
> Bernard? Is anything irrevocably changed by doing so, or is there some
> caveat to avoid irrevocable changes when doing this?

'bzr switch thread-to-send; bzr send -r thread:..-1'

> How do the looms and threads Arthur sets up interact with other,
> non-loom branches he has made from the same upstream? What things are
> possible or impossible with those interactions?

Arther can push any thread to any non-loom branch, and pull any non-loom
branch into a thread. He can also export the loom as a bunch of
individual threads.

-Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20090112/2691e52f/attachment-0001.pgp