new file kind reporting

[Robert Collins]

On Mon, 2007-03-05 at 00:21 -0500, Aaron Bentley wrote:
> Robert Collins wrote:
> > _iter_changes is
> > defined as giving None as the kind for the unversioned side, when
> > reporting newly versioned or unversioned paths. So this test is testing
> > input data to the reporter that is not valid.
> 
> I never intended to define it that way, though the current
> implementation may well be deficient.
>
> > Any objection to this being removed?
> 
> Yes.

Ok, lets talk it around then.

For any two trees, we have roughly two sets of paths: versioned and
unversioned.

Each versioned path has attached to it a file id.

_iter_changes yields data about the current file status for each
file_id, for its path in the old and new tree.

When a file_id I is not present in a tree [lets say in the new tree],
there are four possibilities w.r.t. file path:
A) there is a file in the old tree at the path of I (call that P) in
   the new tree, and there is no file_id in the new tree which occupies
   P. 
B) As for A, except there is a file_id != I (call this J) in the new
   tree mapped to P.
C) As for A except there is no file P in the new tree.
D) As for B except the path P is missing on disk even though an J points
   at it.

What should we output for these cases? I claim that we should output the
following:
A) two items: the fileid I has been removed from old->new, and there is
   an unversioned path P. (the new kind for I is unknown)
B) two items: the fileid I has been removed from old->new, and the   
   fileid J has been added from old->new (the new kind for I is unknown)
C) one item: the fileid I has been removed from old->new.
   (the new kind for I is unknown)
D) two items: exactly as B, except the current-state of the file in new
   is unknown. (the new kind for I is unknown)

I think that B, C and D are clear and uncontentious, because when there
is no file (C) we clearly cannot give a kind, and when another id is
using that path(B,D), it would be very strange to give its details as
part of the output for I.

For A, its possible to argue that because the following conditions are
true:
 - there is a file at the path P in the new tree
 - there is no other id mapped to that path
that we should output the kind of P in the new tree in the output for I.

However, once we start outputting information about unversioned (or
unknowns, a subset thereof), it becomes clear (to me at least :) that
the right thing to do is to consider the file at path P in the new tree
as being output as the details for the unversioned path, and therefor
there is nothing to give the output of I for the new kind.

So thats my logic. You say that the current implementation may be
deficient - how did you expect it to operate for the case of A (or B,C,D
for that matter, if you think I've gotten it wrong).

-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/20070305/a54b4460/attachment.pgp