new file kind reporting

[Aaron Bentley]

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

Aaron Bentley wrote:
> 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.

I should also mention that the other implementation of iter_changes, in
TreeTransform, does distinguish between adds and creates, deletes and
removes.

$ touch FOO
$ python2.4
>>> from bzrlib import transform, workingtree
>>> wt = workingtree.WorkingTree.open('.')
>>> tt = transform.TreeTransform(wt)
>>> tt.version_file('foo_id', tt.trans_id_tree_path('FOO'))
>>> list(tt._iter_changes())
[('foo_id', u'FOO', False, (False, True), ('TREE_ROOT', 'TREE_ROOT'),
(u'FOO', u'FOO'), ('file', 'file'), (False, False))]

This behavior is used in the output of revert, which distinguishes
between removal and removal+deletion: "-   FOO", not "-D  FOO".

And half the reason I was testing the ReportChanges mechanism was to
make sure it worked properly for TreeTransform._iter_changes.

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

iD8DBQFF7CMa0F+nu1YWqI0RAgXvAJ9Ht4MMSlb+nINTQU0HYj9r88khrACfaZ3C
MMZYYM1w/Y7LuA8YxWbBkRc=
=LPou
-----END PGP SIGNATURE-----