21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
|
21
22
23
24
25
26
27
28
29
30
31
32
33
34
|
-
-
-
|
- **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`)
- **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).
# 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()`.
|
45
46
47
48
49
50
51
52
53
54
55
56
57
58
|
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
|
+
+
|
# Maybe TODO
- **Undo** support.
- **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.
- **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.
# 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 almost certainly be one of the last major features.
|