[RFC] Tree.iter_changes

[John Arbash Meinel]

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>>> Aaron Bentley wrote:
>>>
>>>> John Arbash Meinel wrote:
>>>>
>>>> So from my POV, an interface that only supports diffing against parents
>>>> is too limited.
>>>
>>> I realize it is limited, but it is a common case that our data storage
>>> model (both dirstate and our current .knit format) heavily optimize.
> 
> I agree that it's valuable to optimize this case, but I think the
> proposed iter_changes can support that.
> 

...

> That's not what I meant.  I meant that most commands only compare two
> trees, and so comparing against more than one parent efficiently doesn't
> help them.

Sure.

> 
> I agree that comparing against one parent efficiently is a win for other
> commands like diff, but I think we can support maximum efficiency doing
> that for iter_changes, as it stands.
> 

...

>>> I like the approach. But I think we need a way to get at this stuff
>>> without having to build the inventory.
> 
> I don't understand.  Why would that require building the inventory?
> 
> By default, it only emits information about modified files, and it does
> not emit inventory entries, just tuples.

Passing in a Tree object currently requires building an inventory. We
have discussed making this lazy, or something like that. I think it
becomes a little weird to not use the RevisionTree object that is passed
in for anything more than its .revision_id. But I suppose that is a
possibility.

So, I don't know if it is better to pass a RevisionTree or a revision_id
+ revision source object. But I can look at what you have done tomorrow,
and give you more feeback on the specific implementation.

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060920/e8522d1b/attachment.pgp