repository/branch stacking - my current thoughts

[Jonathan Lange]

On Feb 5, 2008 4:59 PM, Robert Collins <robertc at robertcollins.net> wrote:
...
> There are a few ways this can be done; I think all of them have to be
> transitive (if you refer to something that is itself partial, the
> reference chains).
>
> One way is to extend the repository with external references. That is,
> have a set somewhere in the repository that says:
> (revisions, a-revision_id) -> LOCATION
> (inventory, a-revision_id) -> LOCATION
> (texts, a-file_id, a-revision_id) -> LOCATION
>
> etc
>
> This has a problem in that the list can be pretty big. Consider a
> mozilla tree - 50K references. Now a branch with a delta to one file has
> to refer to 50K-1 external references; so the external reference
> management will have to be pretty darn slick.
>
> It also doesn't support random access to references that are not listed
> without going to (all things being equal) 1/2 of the listed reference
> locations and checking their indices.
>
> Another way is to simply provide a list of locations for the repository
> - this scales with places-to-check, not references-made-outside, so is
> simpler to manage. This still suffers access costs of 1/2 the listed
> locations but is conceptually simpler to approach.
>
> A third way is to provide a location in the branch (or arguably a list,
> but I think there is little reason to have an arbitrary list, and a
> single pointer avoid things like 'which one to check first', and 'handle
> some network issues as soft errors rather than hard errors').
>

I can't parse this. Provide a location for _what_ in the branch?

[snip implications]
> In terms of code layout, I think that delegation to other repositories
> should be a core component of the Repository class; I don't think we
> should attempt to do this via layering a decorator on the top, because
> Repository is really a URL located resource in many places in our code
> base, and a decorator doing magic has no URL of it's own.
>
>

This sounds like it precludes the third option, but I'm not sure,
since I don't understand the third option :)

jml