| 278 | | // The deletion happens in a new (uncommitted) revision of the tree, but |
| 279 | | // the cursor is running over the previous revision, so it can still see |
| 280 | | // the deleted key. |
| | 278 | // If we're iterating an older revision of the tree, then the dletion |
| | 279 | // happens in a new (uncommitted) revision and the cursor still sees |
| | 280 | // the deleted key. But if we're iterating the new uncommitted revision |
| | 281 | // then the deleted key is no longer visible. We need to handle both |
| | 282 | // cases - either find_entry_ge() finds the deleted key or not. |
| | 283 | if (!find_entry_ge(current_key)) return is_positioned; |
