Copying extra revisions in sprout

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.

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

The extraordinary proof is also required because because we *guarantee*
that making a fresh branch copies only the necessary revisions and no
others.  Adding an extra-heads feature would subvert that guarantee and
break the "remove-revisions" plugin.

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

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

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

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

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

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

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAkWO0F+nu1YWqI0RAoDLAJ4nHCmtR9naf6FWVad6CwxELff1/ACdHdyw
86TZ83h9QfJ5E6mUo6JTOGU=
=raeh
-----END PGP SIGNATURE-----