[MERGE] More deprecations...

[Robert Collins]

On Thu, 2008-03-27 at 17:45 -0400, Aaron Bentley wrote:


> >>> My overall goal here is to get to a VersionedFiles api which is tunable
> >>> to perform well, and doesn't have cruft on it.
> >> That's admirable, but you still haven't responded to my last email about
> >> the namespace issue.
> > 
> > We seemed to be at an impasse; I don't think you had more to say, and
> > neither did I.
> 
> I asked a question:
> >> > The tuple based keys we've agreed to use are easily (no api changes
> >> > related to keys) extended to use a datatype key prefix.
> > 
> > I don't understand what you mean.  AFAICT, a unified keyspace would
> > require a new API.  How could it be otherwise?
> 
> It wasn't rhetorical.  I would really like to understand why you think
> it would be easy to go from your tuple keys to a unified keyspace.  I
> certainly lean toward a unified keyspace, but I'm not rejecting your
> arguments, just wanting clarification.

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

> > Also, the idiom I used is faster than iter_ancestry, because it does
> > less calls into generators (and we should stop doing full history!). 
> 
> Okay, if your way's better we should do it that way.  But without the
> code duplication, please.

Any suggestions about how to avoid the duplication without keeping the
albatross?

-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/20080328/a297f618/attachment.pgp