[RFC] Repository fasçade

[Robert Collins]

On Tue, 2007-07-17 at 17:58 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi all,
> 
> There are at least two major changes planned in terms of the repository API:
> 1. the repository stacking API
> 2. the elimination of versionedfile from the public interface

Well, this is slightly inprecise. We need to break the assumption that
versionedfile == physical storage. Once thats done its ok to have a
simple api to talk about files-over-time. 

Specifically we probably want:
 - data insertion to be methods on a write group, or other context
object that only exists while writing.
 - data reading can be either on Repository, or on 'versionedfiles' that
have a smaller api than we offer today.

> Therefore, perhaps it makes sense to start from the opposite direction,
> and implement a new repository API.  StackedRepository would be one
> implementation, and we can either implement the new API on our existing
> repositories, or create a new RepositoryFascade class to wrap
> implementations of the current API.
> 
> I think that this would produce a cleaner API that would be
> better-suited to stacking.
> 
> Thoughts?

I think that starting with a new API has several challenges, that i'd
like to see solved before we merge in parts of one. Firstly, I think the
name Repository is fine, and I'd like to see us end up with the same
name, and not have any public API on a different name.

Secondly, it seems likely that StackingRepository needs to be a complete
match for Repository, so whatever API Repository ends up with will be
what StackingRepository implements.

On IRC you said that the key things you wanted were to write a whole new
API, and get rid of the current one as its too restrictive. We did that
with graph.Graph, and so far I've found myself wishing for it about once
every three-to-four days because the new API is smaller and I need to
reimplement stuff the old API had again. I'd like to avoid this problem
by not removing stuff wholesale, rather discussing what should stay or
go.

Replacement API's also tend to land as one big lump, OR, drag on for
months while things get migrated. (the old graph.Graph is an example of
this - it was its incomplete migration that drove its eventual
re-replacement by the new graph.Graph IMO (if it had been more heavily
used, it would have been more obvious that changing it was a win rather
than replacing it)). Things that land as one big lump are really hard to
review, to make each bit as clean as possible. So I'd like to avoid
that. I'd also like to avoid having a long migration period. And yes, I
know these two things are incompatible.

My strong preference here is to fix up Repository's API as needed rather
than write a new one. Design a new one - sure. Then apply that to
Repository in-situ.

-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/20070719/b2589ffb/attachment.pgp