- **Stash** support. First requires merge support.

- **Unversioned files** should be trivial to do.

- The routine(s) which add file content to a repo must, for compatibility with fossil, reject any blobs which approach 2GB (signed 32 bits) in size. Such a blob will lead to OOM crashes in fossil. We also have to refuse to compress blobs that large, as this limit applies to uncompressed sizes.

- `fsl_deck_F_next()` currently includes F-cards which deleted files via a delta manifest in its iteration results. It really shouldn't, as that only applies to delta manifests and whether or not a manifest is a delta is really a purely internal detail.


# Security-relevant

But not otherwise SCM-relevant...

- **Port over `db_unprotect()` and `db_protect_pop()`** APIs, which allow a db to effectively be made read-only except for limited windows where specific sections of it needs to be writable. Related: `db.c:db_top_autorizer()`.

# Maybe (and Maybe Not) TODO

- **Undo** support.

- **Bring the configuration-related state up to date.** The infrastructure is there but the exact list of fossil-supported properties is lagging behind by several years. On the other hand, the majority of such config state is really application-specific and probably has no business being handled by this library. Some settings, e.g. `forbid-delta-manifests`, we internally honor to avoid Grief in downstream repositories. Others, such as the various "ignore globs", have API-level support but are not honored internally: where and how to apply them is an app-level decision.

- **Symlinks**. i have always strongly disagreed with the addition of symlink support into fossil: platform-specific constructs simply have no place in the core of any SCM (with the "effectively necessary" exception of the executable bit). For platforms which don't support symlinks, fossil stores/manages them as plain text files with a single line holding the name of the referenced file. This is *very likely* the route the library will take, especially since the hassles symlink handling caused fossil in late 2020 (long story). Probably the only way the library will support proper symlinks is if someone who uses that feature adds it.
- **Symlinks**. i have always strongly disagreed with the addition of symlink support into fossil: platform-specific constructs simply have no place in the core of any SCM (with the "effectively necessary," as well as unobtrusive, exception of the executable bit). For platforms which don't support symlinks, fossil stores/manages them as plain text files with a single line holding the name of the referenced file. This is *very likely* the route the library will take, especially since the hassles symlink handling caused fossil in late 2020 (long story). Probably the only way the library will support proper symlinks is if someone who uses that feature adds and maintains it.

- **Backlinks**. Crosslinking "should" update the internal list of backlinks from certain text fields, but doing so requires parsing wiki/markdown-format text. See [`backlink.c` in the fossil tree](https://fossil-scm.org/home/file?name=src/backlink.c&ci=trunk) for the gory details. On the other hand, backlinks support only requires parsing wiki links, not the full grammar, so it might not be as painful as it initially sounds... though somewhat more for markdown, where we're required to do a multi-pass scan to handle its linking model. (Technically, we'd also need to handle verbatim blocks to avoid parsing links inside those blocks, but that's a corner case.)
- **Backlinks**. Crosslinking "should" update the internal list of backlinks from certain text fields, but doing so requires parsing wiki/markdown-format text. See [`backlink.c` in the fossil tree](https://fossil-scm.org/home/file?name=src/backlink.c&ci=trunk) for the details. On the other hand, backlinks support only requires parsing wiki links, not the full grammar, so it might not be as painful as it initially sounds... though somewhat more for markdown, where we're required to do a multi-pass scan to handle its linking model. (We'd also need to handle verbatim blocks to avoid parsing links inside those blocks.)

- **Ticket support**. Ticket handling is surprisingly complicated, due largely to the customizability of the ticket database schema. If fossil-compatible ticket supports gets added to libfossil, it will very likely be because someone other than myself adds it! The core artifact data structure supports tickets, so the bits required for adding it are in place.

- **Decimal separator in appendf()**: maybe port in [](fossil:2cdbdbb1c9b7ad2b) to our `appendf()` impl.

# Optimizations

- The fossil implementations of these are not written with port-friendliness in mind, so a complete reimplementation would possibly be necessary.

- In order to support near-arbitrary applications the wiki parsers need to be implemented in such a way that clients can customize (via hooks/callbacks) how links/references are generated.

- The venerable Fossil Wiki format has the lowest priority. In practice markdown has easily taken the lead, and only old (pre-markdown) docs tend to be maintained in that format.

- Alternately, rather than render in the conventional sense, we could potentially output the parsed data in a high-level format (similar to an AST) off of which to base the concrete renderers. That still requires writing per-format parsers, though, which is a drag.


# Non-TODOs

- **Any and all UI-related elements**, including HTML, CSS, and JavaScript. The library will enable such applications but will not provide, e.g., an HTML framework beyond *perhaps* (maybe) wiki rendering.

- **Scripting of tickets**. There are no current plans to 100% mimic fossil's th1 scripting of tickets. Fossil's use of TH1 was one of convenience, not long-term practicality. The library itself will have no "official" scripting language, but is designed specifically to make tying it to scripting engines relatively straightforward. We have a standalone copy of TH1 which "could" be integrated with little work, but doing so would not be an ideal path to go down.