repository/branch stacking - my current thoughts

[Robert Collins]

On Thu, 2008-02-07 at 09:39 -0500, Aaron Bentley wrote:


> 
> > So, one way to make it useful in these circumstances is to allow the
> > branch to be combined on the fly by bzr with the locally missing
> > content.
> 
> Another way is to store a very shallow history.  This would increase
> storage requirements only slightly, while still allowing interoperation
> with current branches.  I doubt the LCA of merges in Bazaar commonly
> goes back even 100 revisions.

Sure; The key difference is 'does another branch need tip of
trunk[referenced thing]@publish-date-of-this-shallow-branch' or some
older revision which has more likely propogated.

> > Now all of these options have some implications:
> >  - mutating operations on the branch/repository have to only affect that
> > branch/repository (e.g. 'bzr reconcile' on one of these deliberately
> > shallow things, needs to not error or fail or even analyse the external
> > references.) It also needs to /preserve/ the external references in file
> > graphs etc, 
> >  - readonly operations such as check really shouldn't access more data
> > outside the actual location being examined than necessary.
> >  - data access that crosses repository boundaries will require some care
> >  - we likely need some way to bring more data into a shallow environment
> > deliberately.
> >  - I think a composite structure like this should be all-or-nothing -
> > missing references are errors, not soft errors.  
> 
> Another significant consequence is that repositories do not know what
> other branches are using their data, and therefore do not know which
> revisions are safe to delete.  This goes against our plans for garbage
> collection, nuclear launch codes, etc.  One solution would be for
> repositories to have a flag indicating whether they permit stacking, and
> this would prevent garbage collection.

This is a good thing to note. If we configure this via repositories -
options one or two - then I agree we have to have a repository flag to
say it has been pointed at. If we configure this via branches however,
then I think it should be pointing at another branch, and this does give
us an indicator that garbage collection should preserve certain data. It
is vulnerable to a rollback on that branch, but this is a reason to
point at reliable branches. (Note that its also vulnerable to a branch
being deleted ;)).

> > 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 is a pretty good argument against doing it as a decorator on
> Repositories, but it doesn't consider other alternatives.  Repositories
> do not have responsibility for retrieving data-- this is the function of
> stores.

I'm entirely open to doing the implementation /within/ Repository by
write code on other objects; I think that writing the smallest feasible
amount of code is a good goal :). However, my point from our previous
thread about the coupling between the defined and tested interface and
the factory of data from disk - the point at which polymorphism in the
API is supported - remains.

-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/20080208/f9367351/attachment.pgp