Unified keyspace (was: [MERGE] More deprecations...)

Aaron Bentley aaron at aaronbentley.com
Thu Apr 3 03:04:05 BST 2008

Hash: SHA1

Robert Collins wrote:
> I think that the implementation using tuple keys can be sufficiently
> generic - like graph.py is - that (type, type-specific, ...) and
> (type-specific, ...) can be both used with no code changes for all the
> delta manipulation and creation logic.

Yes, and even the text-building code for knits is quite flexible about
key type.

> I expect to need to change when
> going from keyspaces of type, to a unified keyspace, is:
>  - the adapter for mapping key prefixes to .kndx files (tiny, 5 lines or
> so)
>  - code using 'low level' calls on repository.*store, rather than e.g.
> iter_file_bytes.
>  - the annotation/graph supporting code in knit.py, which is currently
> very partitioned by type using separate objects, but would need to DTRT
> based on key not on instance.
> I guess this counts as an API change :)

So the VersionedFiles API will never be public?

Sure, for a lot of uses, iter_files_bytes will be a suitable wrapper.
But you're not planning to expose it anywhere?

I guess if hardly anything uses it, then it won't matter when we change
it.  But it still seems like a lost opportunity.  When's the next time
we'll get around to this?

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


More information about the bazaar mailing list