Copying extra revisions in sprout

James Westby jw+debian at jameswestby.net
Tue Oct 2 06:19:14 BST 2007


On (01/10/07 17:50), Aaron Bentley wrote:
> James Westby wrote:
> > For a while now I have been trying to come up with a way to accomplish a
> > certain task with bzr. I have considered various implementations, but
> > none of them fit the bzr model and still appear clean from the outside.
> 
> It would be really helpful if you could start with what you're trying to
> accomplish and go from there.  Even having read your email all the way
> through, I don't know *why* you want to do this, which makes it hard to
> know *how* you should do it.

Yes, I realise that was lacking, but explaining the whole problem seemed
like too much work. I'll give it a go.

When dealing with packaging in a bzr branch you often want to make
changes to the upstream source. These changes should be kept separated,
rather than lumped together so that they can be worked on individually.

This means having separate "threads" of development. I say threads as
they may or may not be branches. Branches would be the obvious fit, but
an early version of this was written and abandoned. Unfortunately I can
obtain neither the source of this, nor information on why the approach
was abandoned.

It was abandoned in favour of the proposed loom plugin, which has some
fundamental concept issues, most notably that it creates git-like
workflow inside a bzr branch.

The other approach is to carry patches around, as you are probably going
to generate a patch for each of these in the end anyway, and it removes
the hidden branch aspect (i.e. git-like workflow).

For the loom plugin you need to copy extra heads as they are the other
branches within the branch. In order to be able to use 3-way merging for
the patch solution (which actually ends up being very similar, but can
degrade to 2-way merging), you also need the bases to apply the patches
to.

Note that the below are proposals for a plugin, the patch would just
allow the behaviours, not place them in core.

> 
> > For reference the four solutions look something like
> > 
> > 1. Have a git-like many branches in one location.
> 
> oppose.  One of the strengths of Bazaar is that each branch is
> addressable as a location.

Yes, I agree. I am trying to avoid this, but it does have some nice
properties, and is being proposed as the loom plugin.

> 
> > 2. Carry patches around with base revisions to apply to for 3 way
> > merging.
> 
> oppose.  Patches are at best a partial solution

You probably want to generate patches in the end anyway, and also allows
you to degrade to two-way merging when the ancestor is not available.
However if you degrade after every branch operation to lose most of the
benefit of the vcs over just using quilt or similar.

> 
> > 3. Use normal bzr branches and have commands to work on multiple
> > branches.
> 
> support.

As a said above this was dropped, for unclear reasons, in support of
number 1.

> 
> > 4. Carry patches around, with bundles to reconstruct the bases for 3 way
> > merging.
> 
> oppose.  Patches are at best a partial solution
> 

As above, but you don't corrupt mainline to support it. You just get
bundles in the tree, and many changes will also give you ugly diffs to
the bundle.

Thanks,

James

-- 
  James Westby   --    GPG Key ID: B577FE13    --     http://jameswestby.net/
  seccure key - (3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM - secp256r1/nistp256



More information about the bazaar mailing list