- **Rebuild**: this feature exercises almost every major SCM feature of the framework except for merging and synchronization. Similarly, deconstruct/reconstruct might be useful for exercising the library. With the exception of missing ticket crosslinking, we have all of the pieces needed to implement this, and the `f-parseparty` test app does much of this work already.

- **Cross-linking of tickets**: the library can read and write them but they cannot yet be crosslinked. Currently, depending on a context-dependent flag, it may error out if it tries to crosslink one or it may silently skip over it.

- **Double-check crosslinking of other types** and make sure that we are not missing newly-added features.

- **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.

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

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

- **Update search index for new content**. The crosslinking steps currently do not do this, pending addition of the search infrastructure. (Code grep keyword: `search_doc_touch`)

- **Stop using char as booleans**. This tree historically uses `char` type for booleans. Now that the tree is C99, we can switch to the `bool` type.

- **Port over the `XDG_CONFIG_HOME`-related changes** for finding the global config db.

- Update [the fossil file format docs](https://fossil-scm.org/home/doc/trunk/www/fileformat.wiki) to document the handful of special cases not covered there, like the convention that tag names must not be purely hexadecimal and control artifacts may not contain tags which refer to that same control artifact (i.e. self-referential tags, like a checkin may legally do (and often does)).


# 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 disagreed with the addition of symlink support into fossil: platform-specific constructs simply have no place in the core of any SCM. 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" 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.

- **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.)

- **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!
- **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.


# Remote Synchronization

- This will be implemented in terms of abstract streaming APIs, very possibly the ones the library already uses for the majority of its file I/O and abstracting output streaming (e.g. it uses an abstract output stream for diff output, rather than writing directly to a buffer).
- This will(?) be implemented in terms of abstract streaming APIs, very possibly the ones the library already uses for the majority of its file I/O and abstracting output streaming (e.g. it uses an abstract output stream for diff output, rather than writing directly to a buffer).

- This will almost certainly be one of the last major features.

# Wiki Parsing and Rendering

- This set of features hovers *right on the edge* of out-of-scope for the core libfossil. Rendering is necessarily output-format-specific and the library has no business defining such outputs. Also...