1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
|
+
+
+
+
+
|
# libfossil Notable TODOs
This page gives a high-level overview of the notable TODOs, or perceived TODOs, as well as non-TODOs (topics/APIs which are either out of scope or are way, way down the line).
# Core SCM (and closely adjacent) Features
In no particular order:
- Merge-related changes made in late 2024, which are not critical to have in the library but which should be ported over so that mixing libfossil APIs with canonical fossil will produce expected results:
- [initial addition of mergestat](fossil:/vdiff?from=245371782aa30688&to=55f136610030f7e7)
- [addtion of that info to the update process](fossil:3a18c95df49f95a5ad72)
- **Port over checkout/repo fingerprint**: this allows detection of when a checkout's repo has been replaced by one with different RIDs. See fossil's `vfile.c:vfile_rid_renumbering_event()`. Calculation and confirmation of the fingerprint [was added on 2021-04-16](8c9cf48702cf3d4f) but still TODO is an attempt at automatic recovery.
- **Stash** support.
- **Unversioned files** should be trivial to do.
- Maybe pending-moderation support (tickets, ticket comments, wiki edits), depending on how centrally-managed such data need to be (i.e. whether it can be delegated to an app layer).
## Checkin
The SQL code related to checkins has diverged significantly from fossil since libf's checkin support was first implemented (the better part of a decade ago). Though libf's is known to work for the cases supported by its existing feature set, it "really couldn't hurt" to audit the checkin algorithm against fossil's. It's okay if they differ, so long as the results are the same. What brings all this up is a corner-case discrepancy discovered in fossil's checkin support regarding merged-and-edited files:
<https://fossil-scm.org/forum/forumpost/03f6b307f89c990b?t=h>
|