computing the resulting inventory from the merge changeset

[Aaron Bentley]

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

duchier at ps.uni-sb.de wrote:
> Aaron Bentley <aaron.bentley at utoronto.ca> writes:

> I am sooo stupid :-/ I was so intent on the prima facie outline of the
> direct algorithm that I never paused to think about what it meant to
> be ordered from top-to-bottom and bottom-to-top.  Of course, it means
> nothing unless it is with respect to a given partial order.  So the
> source entries are ordered bottom-to-top with respect to the source
> tree and the target entries are ordered top-to-bottom with respect to
> the target tree.  They are most definitely not inverse of each other.

It's a fairly subtle problem-- believe me, I didn't get all of it right
the first time, and there are still some flaws.

That is true.  What I was trying to get at, though, is that the
operations must happen in the same total order.  Deletions and
move-out-of-the-way are both removals, and the ordering restrictions on
removals is such that you cannot perform a parent removal before any
child removals have been done, no matter which type of removal it is.

> Now Aaron's doubts are making sense (although his test cases have not
> proven sufficient to expose the logic flaw).  I will now fix my
> algorithm accordingly.  Sorry for being such a dimwit.

Really?  What happened in the case I gave?

So yes, it's also a concern if you're simply applying the inverse
ordering, but I hadn't intended to test that.

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

iD8DBQFDprpy0F+nu1YWqI0RAtB/AJ9PuMC4dOFIA7zHNXAyqwgPfVB99QCfbJCF
A/fL1Wl9jQSCmr+HFi2PhYM=
=VDrk
-----END PGP SIGNATURE-----