[MERGE] Port across errors for shallow branch support.

[Robert Collins]

On Thu, 2008-02-21 at 13:50 -0600, John Arbash Meinel wrote:

> I just wanted to mention 1 thing that occurred to me in all of this discussion.
> 
> When I first envisioned shallow branches, I thought of them as a form of
> standalone branch. Such that they wouldn't share a repository. I think the
> implementation would be easier if we did it that way, but I won't say that it
> must be done in that fashion.

We could do that, but it seems to me to be rather awkward to restrict
space sharing (which is what repositories about) just because we are
grabbing partial data.

> I think Robert is mixing a little bit of "what must happen" with "what would
> happen in the way he would implement it".

"has implemented" at this point :).

> I can understand his point that if you don't provide hints as to which remote
> repositories to use, then just opening the local one (which references 10
> external ones) requires you to open 10 repositories. With the branch giving the
> hint, then you would only open 1.

Cool :)

> You could mark the external references by what revisions you expect to be there.
> And then when searching the ancestry graph you would only open them if you were
> missing the revisions that were referenced.
> However, this starts doing weird things if you start pulling some of those
> revisions locally.

And worse, lookups for unknown revisions will still have to search all
external references. Plus the storage becomes tricksy (a single shallow
copy of mozilla will have at least 50K external references), and needs
to be concurrent operation safe as the core repository is too.

> ~  For example, in an initial shallow branch, you reference revision-foo and mark
> the repository such that 'revision-foo can be found at http://blah'. Now when
> you are going back in history, when you see "parents = ['revision-foo']" then
> you connect to "http://blah" and grab it. So far so good.
> However, if you ever get "revision-foo" into the local repository, then you need
> to know what *other* revisions might be present at the remote site. Either that
> or you have to have a lookaside for "is there any referenced repo that provides
> this revision that I should be connecting to?".

Yup.

> I can see a nice property with branch scaling, in that doing "branch.repository"
> can return a proxy that can connect to referenced repositories. However you have
> some issues that you really need to reference at the branch level so that the
> references can be chained. So now "branch.repository" is saying open the other
> repository *at this branch* in case that branch also wants to reference another
> repository.

branch.open gets this (pseudocode)
try:
    external_url = self.get_stacked_url()
except NotStacked, UnstackableBranch, UnstackableRepository:
    pass
else:
    fallback_dir = bzrdir.BzrDir.open(external_url)
    try:
        fallback_branch = fallback_dir.open_branch()
        fallback_repo = fallback_branch.repository
    except NotBranchError:
        fallback_repo = fallback_dir.open_repository()
    self.repository.add_fallback_repository(fallback_repo)

> And I have to say, going back to "shallow branches are a form of standalone
> branch" seems to simplify a lot of this. Then the shallow repository can
> reference another repository (shallow/shared/etc doesn't matter). Which can
> chain off to as many others as it wants.
>
> The downside, of course, is now you lose the sharing between branches. And if
> you have lots of long-lived initially shallow branches, that could start to grow
> rather large.

You also lose fast branch creation because you start pulling the basis
revision entirely over the wire on new branches. I don't think we should
have to pay this cost.

-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/20080222/06654559/attachment.pgp