Playing with stacked branches

[Robert Collins]

On Tue, 2008-04-01 at 10:51 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> Stacked branches are important to Launchpad, because we don't have
> infinite time or space, and shared repositories don't let us easily
> toggle branches between being public or private.
> 
> So at Tim Penhey's suggestion, I've been playing around with them to
> make sure I have a good idea where they're at.
> 
> I have some comments and questions,
> 
> Design
> ======
> First, I thought we were going to use the term "stacked" rather than
> "shallow", but the current docs and parameters use "shallow".

Good point. I used shallow when I was thinking in UI terms. Perhaps
stacked would be better there too.

> The current implementation requires that the stacked-on branch be in a
> stacking-aware format.  Is that actually necessary?  Is it so that the
> branch can specify whether it is willing to be stacked on?

Its because the current implementation peeks under the hood to get at
the list of packs, and the logic for checking that its really a
compatible format (we can't stack subtrees on a plain-repository for
instance) hasn't been done yet. With the removal of VersionedFile thats
nearly complete the implementation can be updated to read data from any
other repository. We could have made it work on the VersionedFiles
interface, but performance would have been shocking (and launchpad
doesn't need shocking performance).

> With branch6, we moved to storing metadata in the branch.conf file,
> rather than in single files on disk.  Stacked branches store the
> "stacked-on" branch in a single file.  Is this a deliberate design
> choice, or just a case of getting it done the fastest way?

My bad, I did what has worked before. Do you know a good method to crib
from to use the branch.conf file?

> The stacked-on URL is recorded as an absolute URL.  This means that it
> specifies a particular protocol.  Wouldn't it be better, and more like a
> shared repository, if the URL were relative to the stacked branch?  It
> would also mean that the stacked and stacked-on branches could be moved
> as a group, as long as their relative paths didn't change.

That sounds like a good idea.

> Stacked branches reintroduce a "branch-name".  Is this deliberate?

Oh, no. I *thought* actually I was removing that file.

> Implementation details
> ======================
> It would be nice to have "checkout --shallow".  This is currently
> achievable with "bzr branch --shallow; bzr bind", of course.

Agreed.

> There should probably be a way (reconfigure?) to convert from stacked to
> non-stacked.

Agreed.

> Looms don't support stacked branches.  It would be nice if they did.

I would love this. Looms are a bit of an elegant hack; its a shame they
have to be updated continually.

> The smart transport does not handle unknown formats at all well:
> $ bzr info bzr+ssh://aaronbentley.com/home/abentley/stacked
> bzr: ERROR: Could not understand response from smart server: ('error',
> "Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.3)\\n'")
> 
> ^^^ This should be a user error, and it should indicate that the remote
> server does not understand the format.

I think that spiv's been working on some related stuff.

> The error when a stacked-on branch is missing is not very clear:
> $ sbzr log bzr.ab2
> bzr: ERROR: Not a branch: "/home/abentley/shallowtest/bzr.ab/".

Good point, we should catch that and raise an explicit error.

-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: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20080410/ca4dea52/attachment.pgp