_iter_changes API changes...

[Robert Collins]

On Sun, 2007-02-25 at 18:28 -0500, Aaron Bentley wrote:
> 
> I'm not so keen on *only* allowing paths to be supplied, but if either
> paths or file_ids could be supplied, that would be fine with me.  While
> no callers currently use a different algorithm for translating
> user-supplied paths into filenames, commit uses a different algorithm in
> which supplying a pathname causes both the children of the path, and its
> ancestors to be selected.
> 
> That is, "foo/bar/baz" would select not only "foo/bar/baz/qux", but also
> "foo" and "foo/bar".  So if we want to use iter_changes in commit, this
> would be a serious drawback.
> 
> The other issue is that the ids_across_trees algorithm seems very much a
> UI thing.  I think our low-level interfaces should support more
> precision than that. 

Given the time constraints to get this into the current release, I
propose that we keep the interface private - including the reporter
interface (library users can stay with Tree.compare for now), and we
extend it to do what commit needs.

I take your point about allowing id based selection, and agree with the
feeling there: I suggest that we switch to path only *for now*, and as
we get callers that really do want ids we add this - its not obvious to
me how that should be added - i.e. one way is 'just these ids', another
is 'just these ids and their children'. I'd like to note that all our
code currently does is 'just these ids' BUT that the ids are selected by
'just these ids and their children'. That is, we may have a very precise
low level api but we dont use it. And the nested directory inventory
work will likely cause changes in directory children to change the
directory, so the definition gets even more blurred. In short: lets do
id specific logic when we need it, and not before, because its hard to
predict the future.

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/4282f1b7/attachment.pgp