[RFC] Tree.iter_changes

[John Arbash Meinel]

Aaron Bentley wrote:
> John Arbash Meinel wrote:
>>>>>> 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.
> 
> Only for RevisionTrees, not WorkingTrees or ChangesetTrees.
> 
> We need facilities to compare trees, and I think we should use the same
> facilities in status, revert and commit.  That's the purpose of
> Tree.iter_changes.
> 
> So we don't really have an alternative.  We must have a tree-oriented
> API.  It doesn't have to be our only API.  We could also have a
> 'changes_from_parent' API and a 'changes_between_revisions' API.  I just
> think it's cleaner to use the same API in all cases.
> 

Well, for 'commit' we actually need the full inventory, as well as a few
comments about changes (possibly within a restricted set). While for
status and revert we only need the changes (possibly within a restricted
set).

I do want the logic to be unified. But there are some subtle differences
between the two that we need to be aware of. And I want whatever api we
work with to be able to optimize away a lot of our current overhead.


>>> We have discussed making this lazy, or something like that. 
> 
> Actually, I think Robert wants to deprecate the inventory.
> 
> My only issue is that lazy loading can kill the advantage of retrieving
> many revision trees at once.  But we can work around it, I'm sure.

Well, one thing we could do is have the single-request version be lazy,
but the multi-request version be explicit.

> 
>>> I think it
>>> becomes a little weird to not use the RevisionTree object that is passed
>>> in for anything more than its .revision_id.
> 
> We would also use its repository, I think.  Yeah, I know it's still weird.
> 
>>> 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.
> 
> The latest work is here:
> http://code.aaronbentley.com/bzr/bzrrepo/tree-compare/
> 
> I've got it down to ~1 stat per file.  But it's more about API than
> implementation, at this point.
> 
> Aaron

Certainly. We want a nice-to-use-api that can perform a few related
tasks. And probably we should start streamlining/deprecating the other
function calls. (Like list_files() versus iter_entries() versus
iter_entries_by_dir(), etc). BTW, you are going in dir-sorted order, right?

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/20060928/1d26f7dc/attachment.pgp