iter_changes, delta consistency and revert

[Martin Pool]

2009/8/4 Robert Collins <robertc at robertcollins.net>:
> There is some friction here:
>  - revert wants 'enough changes to put specified things back the way
>   they were'
>  - commit and merge want 'enough changes so that the output tree looks
>   like the user expects and isn't corrupted'
>  - status wants to 'show what commit will do'
>  - I think revert is using iter_changes in a symmetrical way, but
>   inventory deltas built on iter_changes are not symmetric, and the
>   iter_changes work I've been doing is likewise not symmetric.
>   Specifically tree.iter_changes(basis, specific=foo) !=
>   basis.iter_changes(tree, specific=foo), where expansion for
>   consistency is concerned.
>
> I have thought of of a few options:
>  - inspect the iter_changes output inside revert, and discard things
>   that are not needed.
>  - make consistent expansion an optional flag to iter_changes and have
>   revert use that.
>
> However, we've had a number of bugs (going from memory) to do with
> revert and dirstate; I'm not at all sure that this is a coincidence -
> the very bug I'm fixing, to ensure consistent deltas, may well prevent
> those bugs in revert.

I talked a bit to Robert in real time so I won't repeat the whole
thing but in brief:

In fairly obscure cases with renamed directories I think reverting a
bit too much is acceptable.

It would be nice for revert to construct the specific-file delta back
to the basis tree and apply that, if it currently is doing something
to reverse it.

An option to iter_changes that gives you an unsafe delta is probably
an invitation for this kind of bugs to get back in.

-- 
Martin <http://launchpad.net/~mbp/>