62
63
64
65
66
67
68
69
70
71
72
73
74
75
|
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
|
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
|
if( nConflict && !allowConflict ){
fossil_fatal("abort due to unresolved merge conflicts; "
"use --allow-conflict to override");
```
The corresponding code in libf looks *much* different than that now, and it's not currently (2021-09-17) clear whether or how that change would need to apply to libf's impl.
## Status and Symlinks
There's a slight inconsistency in "status" results vis a vis fossil(1) when using a symlink. In the admittedly odd case below, there's a checkout of project X on my hard drive, and another to that same checkout on a RAM disk. In order to avoid data loss if my system crashes, the file being worked on in the RAM disk is a symlink to a file from the on-hard-drive checkout:
```
[stephan@nuc:/home/ram/stephan/foo]$ l XYZ.test
lrwxrwxrwx 1 stephan stephan 39 Jul 19 15:41 XYZ.test -> /home/stephan/.../XYZ.test
```
(The working copy is on a RAM disk because this is a test-driver script and these tests are extremely I/O-heavy.)
Where "fossil status" reports (correctly) that all files are up-to-date, libf may incorrectly report, in the RAM-disk copy, that the file is out of data:
```
$ f-status
...
Local changes compared to this version:
MODIFIED XYZ.test
```
though running a diff clearly shows that it's current.
libf's symlink support has never been fleshed out (and has been outright ignored in numerous places as a result of my personal stance on storing symlinks in an SCM), so this disconnect could be in any number of places in the library.
# 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_authorizer()`.
|