Timeline

* feat(cli): checkout-free snapshot, per-path log, cat --at and diff --json

repo snapshot commits one file's bytes onto trunk with no checkout, a no-op when they equal the tip. repo log --path lists the check-ins that changed a path, repo cat --at reads a file as a version holds it, and repo diff --json A B [PATH] diffs two versions. Exit 2 means not found. A snapshot re-checks the check-in stamp inside its write transaction and retries, so concurrent processes build one linear trunk.

Tracked in #451

* test(cli): cover log across a rename; order exit statuses in the docs

Tracked in #451

* fix(db): convert Julian days to the millisecond SQLite gives

log --json printed most check-in times 1ms before their D card: db.julianToTime truncated where SQLite's date.c rounds with (sqlite3_int64)(r*86400000.0+0.5). fsltype.MillisFromJulianDay now does exactly that, JulianToTime and ScanTime use it, and ScanTime rounds the time.Time ncruces hands back to the millisecond as well.

* fix(cli): print usage errors on stderr and pin their exit status 80

The documented status was right for the binary; go run turns it into 1. Usage text went to stdout, so an embedder reading stdout saw it on a failure. The doc now says which status a measurement under go run shows, and a test pins 80 for an unknown flag, a missing flag or argument and an unknown subcommand.

* fix(cli): refuse a snapshot path holding a control byte or a reserved name

validateRepoPath now applies fossil's own rules for a new file name: file_is_simple_pathname in strict form (deck.StrictPathname), no byte below 0x20, and file_is_reserved_name, whose existing port in deck is exported as IsReservedName. Each refusal exits 1 and names the reason.

* fix(cli): diff A B PATH matches fossil's PATH rules

A PATH in neither version printed [] and exited 0; fossil diff --from A --to B fails with "not found". It now exits 2 (not found), and PATH also matches a directory, as fossil's file_dir_match does. The test runs fossil on the same repository as the oracle.

* fix(cli): refuse a snapshot into a repository with no main-branch check-in

When the main branch resolved to nothing, snapshot took the repository for empty and committed a second root beside the existing history. It now treats only a repository with no check-ins as empty, and otherwise fails at exit 1 naming the branch.

* test(cli): compare log across a rename with fossil finfo

The rename test built its history through manifest.Checkin and checked our own idea of the result. It now builds the history with the fossil binary and compares repo log with fossil finfo on the same repository: both stop a name's history at the rename. The doc tells an embedder how to follow a file across renames, and where log differs from finfo.

* fix(db): set busy_timeout before any other pragma on open

The drivers build the DSN's _pragma parameters from a map and run them in that order, so journal_mode or foreign_keys often ran before busy_timeout. An open while another process held a lock then failed at once with "database is locked" instead of waiting: one cause of TestSnapshotConcurrentProcesses failing under -tags test_ncruces.

* fix(cli): hold the write lock from snapshot's read of the tip to its commit

Under -tags test_ncruces, TestSnapshotConcurrentProcesses failed 8 of 20 runs. Besides the open-time lock error fixed in db, a snapshot read the tip's manifest outside any transaction while another process's check-in re-deltaed it, and failed with a hash mismatch. A snapshot now runs in one bound write transaction from the read of the tip to its commit, so no other check-in can land in between; the optimistic retry loop it replaces is gone. check-in: 90345545d3 user: [email protected] tags: main, trunk

Fossil treats the ticket table, ticket.tkt_ctime, the ticketchng table, ticketchng.tkt_rid and ticketchng.tkt_user as optional. Each schema here must derive the rows fossil rebuild derives; all fail today. check-in: 40a0ba9626 user: [email protected] tags: fix/ticket-optional-columns, main, trunk

repairTagPropagation re-propagated tags from every primary parent in the repository at every gate, so the gate at the end of a sweep, clone or sync cost the repository, not the batch. The batch now records the primary parents it writes plink rows for, and the new parents of a reparent, in a set beside its leaf schedule; the set is marked, rolled back and reset with the schedule, and the gate propagates from it alone. A rebuild links every check-in, so its set is every primary parent and nothing changes there.

A phantom-fill cascade's parents are known only to the cascade, so each cascade batch runs the gate itself before it commits rather than leaving propagation to the end of the sync.

Tracked in #432. check-in: 08820292b8 user: [email protected] tags: main, perf/tag-repair-batch, trunk

repo snapshot commits one file's bytes onto trunk with no checkout, a no-op when they equal the tip. repo log --path lists the check-ins that changed a path, repo cat --at reads a file as a version holds it, and repo diff --json A B [PATH] diffs two versions. Exit 2 means not found. A snapshot re-checks the check-in stamp inside its write transaction and retries, so concurrent processes build one linear trunk.

Tracked in #451 check-in: beed361c03 user: [email protected] tags: feat/cli-snapshot, main, trunk

verify.Verify expected a leaf for every check-in with no child at all, so it reported merged branch tips and branch points whose children are on other branches, and the arrival-order states repo-state Section 7.3 allows. Verify no longer recomputes one expected table. leaf.Audit, which applies the Section 7.2 test leaf.Check uses, reports a row whose same-branch child carries a branch row written once it was linked, and a check-in carrying a branch row with no same-branch child and no row, excusing the parents checkPlink finds a reparent took a child from.

Every conformance case comparing the leaf table now also runs Verify on it, and repostate.7.2.verify-leaf-table checks that Verify reports a dropped and a planted row.

Tracked in #433. check-in: c6db63319e user: [email protected] tags: fix/verify-leaf-rule, main, trunk

Update matched files by name, so a local edit to a file the target renamed was left behind as an untracked file under the old name while the new name got the target's content.

path.NameChanges ports fossil's find_filename_changes with revOK: the renames along the primary path from the checkout's version up to the common ancestor and down to the target, a rename on the way up taken backwards. Update uses it as update.c does: a changed file the target renamed is matched to the target's file under its new name. A merge is written under the new name and the old name removed; when the target only renamed the file, nothing is written and the edit stays under the old name, untracked, as in fossil, which Unmerged now reports. A local rename is not followed, as in fossil.

fossil 2.28 interop tests compare both directions: a target-side rename and edit, a target-side pure rename, a local rename of a file the target edited, and a rename on the checkout's own branch followed backwards to a sibling.

Tracked in #445 check-in: c88a801cf9 user: [email protected] tags: feat/submanifest-reader, main, trunk

# Conflicts: # CHANGELOG.md check-in: 044f6da5e0 user: [email protected] tags: feat/submanifest-reader, main, trunk

# Conflicts: # CHANGELOG.md check-in: 2f61d4898f user: [email protected] tags: feat/submanifest-reader, main, trunk

# Conflicts: # CHANGELOG.md check-in: c851990f41 user: [email protected] tags: feat/submanifest-reader, main, trunk

Port the remaining branches of fossil's vfile_check_signature. A missing file is marked changed with mtime -1, a removed file is marked changed, and the permission half sets chnged 6-9 for exec-bit and symlink changes (returning to 0 when undone), honouring the allow-symlinks setting: off, a symlink is seen as what it points to; on, as itself, its content its target's name.

Status reports the mode changes as fossil's changes command labels them (executable, symlink, unexec, unlink). Commit records the permission it finds on disk, l included, with a symlink's target as its content. Where the storage has no file modes (MemStorage) or on Windows, the recorded permissions are kept, as fossil on Windows keeps them. ScanENotFile now refuses a non-file where a tracked file belongs, and merge scans with it as fossil's does. Extract still writes a missing file without Force.

Interop tests run the same edits through fossil changes and go-libfossil status on one checkout, in both orders and with allow-symlinks on and off, and compare a commit's F cards with fossil's.

Tracked in #449 check-in: 2d2e62d420 user: [email protected] tags: feat/submanifest-reader, main, trunk

* 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. check-in: a71bf662ee user: [email protected] tags: main, trunk