Unified keyspace (was: [MERGE] More deprecations...)
Aaron Bentley
aaron at aaronbentley.com
Thu Apr 3 03:04:05 BST 2008
-----BEGIN PGP SIGNED MESSAGE-----
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?
Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFH9DsV0F+nu1YWqI0RArv2AJ98U0BNMflyR74BkjFEkLvz2CTQ+ACfc3Ai
QdYw+oqUxSWX/jrSlQuccxY=
=EP0S
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list