[RFC] Repository fasçade

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> 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.

If you look at my implementation, you will see that StackedRepository is
being tested using the exact same tests as VersionedFileRepository, to
ensure that this happens.

> 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.

I don't think the situations are really comparable.  RepositoryFacade
will not be a reasonable alternative until it supports all of our
Repository uses.

With Graph,
- - I wanted a smaller interface, so that it was more reviewable.
- - I wanted not to YAGNI.

On the other hand, if you look at the VersionedFileRepository, I think
it's a huge success.  I was able to support 99% of RevisionTree's needs
with just two methods.

> Replacement API's also tend to land as one big lump, OR, drag on for
> months while things get migrated.

I'm proposing that the RepositoryFacade would support all uses of
Repository, so it would be one big lump, with deprecation of the
Repository object happening at that time.

> Things that land as one big lump are really hard to
> review,

Well, my faith in the review process is already pretty weak.  If I can't
get you to review the graph.Graph change, I can't really expect anything.

> 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.

- From my POV, the sooner we get a proper API for Repository, the sooner
we can get them streaming.

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

I really don't think you can do that without implementing the new API.
I don't think it's especially hard to implement the new API as a wrapper
on the old.

> Then apply that to
> Repository in-situ.

One incremental approach that could work would be to make
RepositoryFacade a base class of Repository.  That would allow us to at
least make the new API a separate object.

But really, deprecating all the methods of Repository is a waste of
time, in my opinion.  All the good method names are taken (a la
get_revision_graph).  Which means introducing not-good names or else
doing API breaks, in order to deprecate the bad old behavior.  We're on
a performance drive, and in my opinion, we're not getting there fast
enough.  I don't want to spend my time doing an endless deprecation
dance.  Calling it something other than Repository means we can achieve
a sane API without breaking compatibility or wasting too much time.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGn5ow0F+nu1YWqI0RAozCAJ4uz56wgNAigsU9czY+gtuWNlSX8gCeISGW
q3bQAohUvPetnWUF+xMpt1M=
=/3Q4
-----END PGP SIGNATURE-----