[RFC] Tree.iter_changes

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:
>>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).

For commit, we need the basis inventory and the (selected) changes, but
we don't need the working tree inventory.

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

I think status and diff are supposed to predict what commit will do, so
it seems as though subtle differences would be bad.

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

Yes, I was thinking of that, too.

> 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?

Yes indeed.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFFHDjx0F+nu1YWqI0RAkHSAJ9O0tYARjw4ArkGiXow9vXXPEHSGgCcCKV/
cBXRgt8Zb8sns0bBxu6B6Ug=
=rXyh
-----END PGP SIGNATURE-----