Artifact Description [3097f65e89]

Artifact 3097f65e898befc15247b849fef74b90ee4b985750aafe9aae34a8264f979a87:

• File internal/checkout/status_test.go
  • 2026-10-18 20:59:23 — part of check-in [a71bf662ee] on branch main — fix(checkout): record and trust vfile.mtime as fossil does (#444)

    * fix(checkout): record and trust vfile.mtime as fossil does

    go-libfossil wrote vfile.mtime = 0 everywhere and hashed every file on every scan, so it and fossil rehashed a go-libfossil checkout on every command.

    The scan is now fossil's vfile_check_signature: a file whose size matches its artifact (blob.size of mrid) and whose mtime matches vfile.mtime is taken as unchanged without being read, unless ScanHash is given or the mtime-changes setting is off; the scan stores the file's mtime in whole seconds and runs its updates in one transaction. Status, commit, merge, revert and extract use the default scan, as fossil's commands do.

    Mtimes are recorded where fossil records them: extract and update store the mtime of each file written with its artifact's content, an unchanged file keeps its mtime through LoadVFile (fossil's update transfer and in-place commit), committed files keep theirs, revert stores the restored file's, and SetMTime stores the time it gives. Undoing a rename drops the mtime, since the file was not checked.

    One deliberate difference: an mtime not older than the current second is stored as 0, so the next scan (ours or fossil's) hashes the file and an edit that keeps the size within that second is still seen. A stored 0 is never trusted.

    MemStorage now stamps each write with a new mtime from its own clock, as a filesystem does, so in-memory checkouts see same-size edits.

    Status on the sqlite repository's 2,220-file checkout: about 250 ms before, about 30 ms after.

    * test(checkout): pin the same-second guard against fossil

    A same-size edit in the second a file was scanned is committed, and fossil 2.28 reading a row the guard stored as 0 reports the edit. Both tests fail with the guard removed. The guard's comment and the CHANGELOG name it as the one deliberate difference from vfile_check_signature.

    * fix(checkout): record the mtime of each write as it happens

    Extract and update statted their files only after every file was written and vfile reloaded, so an edit in between was recorded as the written content. They now stat each file right after writing it, as fossil's vfile_to_disk does, and carry that mtime to the row. Revert and the new writtenMTime read the clock before the stat, as the scan does.

    A caller's Env without a Clock now gets the real clock, as Storage defaults to the OS; scans read it. The mtime-changes setting is read from the repository only: go-libfossil reads no global fossil settings, which the comment and CHANGELOG now say.

    New tests: an edit after extract's or update's write is seen, a stored 0 is never trusted, and a simulated clock at a realistic time drives the mtime fast path. (user: [email protected], size: 6732) [annotate] [blame] [check-ins using]

  • 2026-10-19 00:33:59 — part of check-in [c851990f41] on branch feat/submanifest-reader — Merge remote-tracking branch 'origin/main' into feat/submanifest-reader

    # Conflicts: # CHANGELOG.md (user: [email protected], size: 6732) [annotate] [blame] [check-ins using]

  • 2026-10-19 14:41:42 — part of check-in [47f89f0798] on branch feat/submanifest-reader — Merge branch 'feat/submanifest-reader' into feat/cones

    Update's rewrite meets the sparse worktree: a file outside the cone is a record-only step, counted in OutOfCone, and never planned, scanned, checked, written, backed up as NAME-original or chmodded; reloading vfile moves its record to the target. SetCone records the mtime of each file it materializes, as Extract now does. (user: [email protected], size: 6732) [annotate] [blame] [check-ins using]