| Ticket Hash: | fa798aee061fb74841148af85fc3b2176489fb74 | ||
| Title: | OCX's wait in a checkout waits on nothing with the client's Fossil, which opens no .fslckout for sql --no-repository | ||
| Status: | Open | Type: | Code_Defect |
| Severity: | Normal | Priority: | Medium |
| Subsystem: | fossil | Resolution: | |
| Last Modified: |
2026-11-02 12:05:51 8.8 days ago |
Created: |
2026-11-02 11:52:51 8.8 days ago |
| Version Found In: | |||
| Description: | ||||
|
OCX waits for a command in a checkout first on that checkout's own database, by `fossil sql --no-repository :memory:` there (Place#hosted, docs/fossil.md). The old root's Fossil 2.27 (gcc, with Tcl) opened .fslckout for that; the client's, built from the same source by ocx-rootfs/build-rootfs.cr (clang 18, no Tcl, no TH1 hooks), opens only an empty main database and Fossil's settings. So on the client the wait goes through at once and each run again meets the holder: a person's fossil command holding a session's checkout makes OCX's add or commit fail after its reruns, without waiting. Fossil 2.27's sqlcmd.c sets no checkout with --no-repository on any path read so far, so what opened it in the old build is unknown.
Found 2026-11-02 when the stand-in fossil first ran under Crystal 1.19. spec/ocx/fossil_spec.cr now holds its two examples of this wait pending on a host whose fossil does not open .fslckout. Fix to decide: make the wait not depend on the build, for example by OCX opening .fslckout through its own SQLite connection with a busy timeout, as Fossil::Reader::Direct already reads repositories. | ||||
| User Comments: | ||||
|
x86-1-session added on 2026-11-02 12:05:51:
Review of check-in 9c32130f12 (the move to Crystal 1.19.1), by stone, in stone's own words below. I'm putting it on the record because stone's clone of ollama is anonymous and
| ||||