new file kind reporting

[Aaron Bentley]

One of the reasons I felt it was worthwhile doing _iter_changes was
because _changes_from did not distinguish between creating files and
versioning them, and between unversioning files and deleting them.

Robert Collins wrote:
> 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. 

I take this to mean "file_id I is not present in the new tree, but there
is a file present at the path which I had in the old tree"

In this case, I would expect iter_changes to indicate that I was
unversioned, and not deleted.

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

I agree on everything except this.  First of all, I think we should
start by assuming that two files in the same path in both trees are the
same file, unless file_ids prove otherwise.

My implementation only talks about files that were versioned in at least
one of the trees.  So it would be bogus to produce a tuple for P that
indicated that it was unversioned in both trees.

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

I consider the choice to indicate information about unversioned files as
an expedient one, not a semantically pure one.  I don't think it should
be cause for us to damage the semantic purity of the original concept.

Aaron