_iter_changes API changes...

Robert Collins robertc at robertcollins.net
Sun Feb 25 21:53:26 GMT 2007


Hi Aaron,
    I'm preparing to do a rather large commit to dirstate altering
_iter_changes, and I'd like to run the conceptual differences past you
to ensure I'm not doing something silly.

First I've folded the paths2ids call into _iter_changes, because: all
users (I tracked em down) of _iter_changes were starting with user
supplied pathnames, and folding the call into the iterator allows
specialisation by dirstate, for extra tasty low overhead.

Second, the current API returns adds/changes before deletes, but with
dirstate we get those in-order as we walk.  The fold-in of paths2ids
also means that we can get some entries out of order: if we start with a
user path of 'subdir', which includes in the source tree another dir
called 'moved-dir' which was moved to '/moveddir', the entries for
'/moveddir' should be output before those for subdir if we require
sorted order. So I've changed the definition slightly to say that it
*may* do this. I figure its cheaper to sort a list of (say) 100 changed
entries in the output layer, than to have to do two passes to identify
all entries in the [large] memory structure and then diff them.

Thirdly, something I have not done yet is to expose unversioned files in
the tree delta output, which will let tree delta clients avoid a
tree-scan to find unknowns - they will need to filter the unversioned
list to determine what is unknown, but thats relatively cheap.

Lastly, I have not yet, but I plan to today, changed the path output
field to (oldpath, newpath), to eliminate all id lookups. An alternative
would be an intertree api - tree.get_other_path(other_tree, id=None,
path=None), which would translate - for inventory based trees its just
an id lookup, for dirstate we lookup under the current path and return
the pointer from the dirblock details for the other tree.

Cheers,
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/20070226/7e87e818/attachment.pgp 


More information about the bazaar mailing list