Maintaining multi-layered, interdependent branches

[Ben Finney]

Thanks for your response. It raises a number of further questions :-)

Robert Collins <robertc at robertcollins.net> writes:

> On Sat, 2009-01-10 at 12:10 +1100, Ben Finney wrote:
> > 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/

That URL gives me a “500 Internal server error” response.

Is there a reason for keeping those documentation files separate from
the rest of the Bazaar documentation?

> > 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)

[…]

> > What is the proposed workflow for Arthur?
> 
> Generally, hack on a feature. To pull new code from Bernard, shelve
> any current uncommitted changes

Is it a problem if Arthur commits those changes before pulling from
Bernard?

Once changes are shelved, does Arthur need to be in the same thread
when unshelving those changes? What will happen if he's in a different
thread and tries to unshelve them?

> switch upstream-checkout, bzr pull, bzr up-thread --auto top:

Why are those options needed for that ‘up-thread’ command? If this is
the general case, why does the command not do this in the absence of
any options?

> > 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.

I'm not sure I understand about “topo sorted order”. The dependency
relationships between the above names were deliberately chosen to make
the order not a simple stack; how should that structure be represented
in a loom, without losing the divergent nature of some of the
dependencies?

> > 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. […]

Sorry, you seem to be answering a “why” question here that I didn't
ask. I was asking what Arthur needs to do.

> > 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.

Are there irrevocable changes made by doing ‘record’? Or is it
something that can safely be done at any time without changing the
loom structure?

Does it make a difference which thread is current when Arthur issues
the ‘record’ command?

> I don't know what Arthur does today, so I can't comment on what not
> to do.

The “existing practices” was referring generally to a regular Bazaar
workflow without looms; what practices of a user like Arthur, familiar
with Bazaar but not with looms, are no longer appropriate in a branch
that has been converted to a loom?

> > 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'

Okay, so this *doesn't* include a ‘record’ step. Is that not necessary
to send a patch bundle to Bernard? Remember that Bernard doesn't have
looms.

I presume from the lack of answer that the above commands don't change
anything irrevocably in Arthur's branch.

> > 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.

By what you said above, Arthur can only do this by doing a ‘record’
first, is that right?

> He can also export the loom as a bunch of individual threads.

By “individual threads” here, do you mean “separate branches, each of
which corresponds to a thread”?


Thanks again for answering questions on this system.

-- 
 \       “Faith, n. Belief without evidence in what is told by one who |
  `\   speaks without knowledge, of things without parallel.” —Ambrose |
_o__)                           Bierce, _The Devil's Dictionary_, 1906 |
Ben Finney