While thinking (and thinking ... and thinking ...) about issue #3220 last week,
I stumbled upon a belief that not only was our "how did the mergeinfo change"
logic highly inefficient, but that the approach might be also incorrect.
The algorithm today is pretty basic:
- fetch mergeinfo in the previous revision
- fetch mergeinfo in the current revision
- compare, contrast, and combine
But this is far too naive. A simple use-case that causes wrong results was easy
to find: deletion of a subtree inside which there lives some mergeinfo.
Bug
Major