Copying extra revisions in sprout
James Westby
jw+debian at jameswestby.net
Tue Oct 2 17:44:07 BST 2007
Hi Aaron,
Thanks for your input.
On (02/10/07 09:20), Aaron Bentley wrote:
> James Westby wrote:
> > 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.
>
> That helps tremendously, and it's actually a problem I've thought about
> since Ubuntu Below Zero in 2005. Essentially, it's solving the same
> problem that Quilt and Stacked Git solve. I've never been in a position
> where I actually needed "Stacked Bzr" as I and David Allouche called it.
> And since I didn't have the itch, I haven't pursued it, because I may
> not understand all the subtleties for people who are in that position.
Yeah, I'm trying to avoid just assuming that we need Stacked Bzr, as it
might not be the right solution, but for now it does seem appropriate.
>
> > 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.
>
> I've always thought that branches, with some additional management
> commands, were a great solution for that. So to me, the claim that
> branches aren't suitable is an "extraordinary claim" that requires
> "extraordinary proof".
Yes, I would like to know the reasons for the abandonment of that
project.
> > 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.
>
> If you mean one tree, many branches, and switching among them, I have no
> problem with that concept.
>
> I don't believe that concept requires that the branches all be in one
> physical location, so it doesn't lose Bazaar's one-branch-one-location
> promise.
Well as the plugin is outlined it is one tree switching branches, but it
appears as though those branches are all obtained by using 'bzr branch'
of a single branch. This is playing with the terms a little bit, which
was why I was trying to avoid saying many branches in one location.
>
> > 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).
>
> But of course, patches can't convey all the information that branches
> do. Their rename support is funky, their directory support is weak,
> symlink and execute bit support nonexistent.
Indeed. We need patches eventually, but having the extra information
while working would help.
> > 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.
>
> If it comes to that, the plugin can also register a new format to
> support the extra-heads functionality.
Ah yes, that is true. It still breaks the remove-revisions plugin, and
would involve an additional format bump for every bzr format bump, when
putting it in core seems like a limited overhead. (Though the lack of
users in core is a downside).
> >>> 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.
>
> I have strong doubts that the nice properties are inextricably tied to
> losing location-addressable branches. You can stick branches in a
> hidden directory-- maybe even .bzr/branches/
That seems appealing. Am I right in thinking that this still requires a
format bump?
In terms of implementation I guess in Branch.spawn() you just spawn the
main branch, and then ask any sub-branches to spawn as appropriate?
It would be fun having upgrade warnings though.
Also, I assume that remove-revisions either uses Branch.spawn(), or gets
the heads by recursively trying to open branches or similar, which would
make this change safe. I haven't looked to see how it does work.
>
> >>> 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.
>
> You can always degrade to two-way merging-- just specify revision 0 as
> the base.
But you still need the revision in that case, which is what extra-heads was
trying to do, and so you always can do 3-way.
By patches degrading I meant that you could just apply the patch.
> >>> 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.
>
> The raw form of bundles is binary, so if you had a raw bundle, diff
> would just say "binary files differ". It's certainly conceivable we
> could allow "send" to emit raw bundles.
>
> But sticking bundles in the working tree doesn't merely produce ugly
> diffs, it's also an ugly concept, because bundles are essentially
> partial repositories, and you're sticking them as data inside a repository.
>
Yeah, I'm certainly not going this route, it was just another solution I
saw.
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