Unified keyspace (was: [MERGE] More deprecations...)
aaron at aaronbentley.com
Thu Apr 3 03:04:05 BST 2008
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
> - code using 'low level' calls on repository.*store, rather than e.g.
> - 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?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar