[MERGE] Make TreeTransform update the tree inventory on kind changes

[Aaron Bentley]

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

John Arbash Meinel wrote:
> 2) According to Aaron, we already have the information we need. Apparently we
> actually have *too* much information.

We *would* have too much information if we stored kind change data.

> I think his recommendation was something
> along the lines of:

This was my original recommendation, but James pointed out that when
apply_insertions runs, deletions have already been performed, and
therefore the original kind is inaccessible.

> It feels a bit odd to be checking after the fact, when you can simply compute
> it as you go ahead of time.

The more data you store, the more data you must manage.  For example, if
the content is deleted later, you must remove the entry from the list,
and if new content is supplied still later, you must re-add it to the list.


> But as long as it doesn't add a *lot* of overhead,
> it seems ok.

It adds *less* overhead to check for kind changes only once the final
shape of the transform has been determined.

> 3) At a minimum, I don't really like that all the other checks use the state
> of the transform object (trans_id in self._new_name, etc) and this is using a
> local variable. It certainly feels like kind changes should be part of the
> state of the Transform object.

They are, and they are already implicit in the data we have.  So there
is no reason to look for them until we are actually applying the transform.

We use plenty of local variables when applying transforms.
Unfortunately, we can't do that here because applying deletions makes it
impossible do the calculations needed to apply insertions.

This approach is exactly the approach I asked James to take.

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

iD8DBQFIk5Jc0F+nu1YWqI0RAp3ZAJ9/QAe/YLV6vjqMjI/jwjj5aACW8gCfSKBn
xCQwkSEsMP8awAA7n5b/m6o=
=lB99
-----END PGP SIGNATURE-----