Discovered 2021-11-18: A hypothetical problem which has not yet appeared but can potential do so in the face of a long-running app which performs "just the right" rollbacks between non-rolled-back operations...

Each fossil context object (`fsl_cx`) stores several `fsl_id_bag` objects which keep track of various RIDs for caching and fast-tracking purposes. It is hypothetically possible, in a long-running application (as opposed to the various `f-apps`) that those caches may pick up RIDs which have since been rolled back and thus are no longer in the database. That in itself is harmless, but future db ops may re-inject those same RIDs, leading to semantic mismatches between the caches and the in-db records.

On solution would be to store a copy of each such cache at the start of each transaction and revert its contents if a transaction rolls back. The minor catch with that is that the db layer doesn't "really" know about `fsl_cx` state (it does a little but, but that's unfortunate) and doesn't currently have a way to communicate to the `fsl_cx` that a transaction has finished. Another solution, though heavier, would be to abstract all access to those caches via internal APIs and use two ID bags for each cache: one for use while a transaction is active and one for state which has survived a transaction (or run without one). When a transaction rolls back, clear the "staging" bags and when one commits, move those records into the long-term bags.


# Crosslinking...

# f-apps-specific

## f-vdiff
2021-04-12: The issue described below may have been resolved by the bug fixed in [](2791e665cca2eae2).

f-vdiff, when comparing to the local checkout, needs to be able to recognize renames. Case in point:

Running `f-parseparty -t c --crosslink` generates the expected number of mlink/plink entries but *sometimes* leaves (as it were) some commit other than the tip marked as a leaf, which causes `fossil update` to warn about having multiple leaves. We can get around this by running `fsl_repo_leaves_rebuild()` after it crosslinks everything, but that would simply hide the bug (if it *is* a bug - see below), which would presumably appear again at some point after a single checkin gets processed.
```
[stephan@nuc:~/fossil/fossil]$ f-vdiff . . 
f-vdiff: ERROR #107 (FSL_RC_NOT_FOUND): Cannot stat file; /home/stephan/fossil/fossil/src/codecheck1.c
```

That said: it's unclear whether this is a genuine bug or a side-effect of an unfortunate parsing order. `f-parseparty` currently (as of 2021-03-11) recomputes the leaves by default if it crosslinks any checkins or tags (noting that tags can close checkins). Despite the code comments in the leaves computation, it is not "slow", taking an insignificant amount of time to run, even on the fossil and sqlite repos.
That file, along with many others, was moved to `../tools` in this checkout. We have the state necessary to do this check (namely, the vfile table), it just needs to get done).

# Reverting
## f-revert

`f-revert` needs to be smart enough to know when it can/should/must clear the vmerge table, or it should refuse to work on individual files so long as a merge is pending.