The two freshen tests built a fixture and never ran freshen. They now run gen and freshen through the command entry point on a temp dir:
unchanged tree: the manifest lists the same entries as before;
a modified file (once with a new size, once with the same size and a different mtime), a new and a deleted file, one per subtest: the rewritten manifest reloads and lists exactly the tree, each file with the size and hash of its content and its mtime on disk, and check --no-extra-files passes on the tree.
They use the real filesystem rather than the in-memory one because gen and freshen recognize their own manifest by file identity, which the in-memory filesystem does not support.
New fetch tests run the command against an httptest server that serves a manifest generated from the files it serves:
a tree with nested directories lands complete, with nothing else left behind;
a file served at the listed size but with different content makes fetch exit 1 and leaves no file;
a destination left by an interrupted fetch of an older tree: every listed file is downloaded again, those already present included, and replaced; a file the manifest does not list is left alone. #101 changes this behavior; it can flip the expected request list in this test and point it at its destination flag.
The existing downloadFile tests are unchanged. Writing these tests turned up no bugs in freshen or fetch.
Model: opus-5-5
Closes https://git.eeqj.de/sneak/mfer/issues/66.
The two `freshen` tests built a fixture and never ran `freshen`. They now run `gen` and `freshen` through the command entry point on a temp dir:
- unchanged tree: the manifest lists the same entries as before;
- a modified file (once with a new size, once with the same size and a different mtime), a new and a deleted file, one per subtest: the rewritten manifest reloads and lists exactly the tree, each file with the size and hash of its content and its mtime on disk, and `check --no-extra-files` passes on the tree.
They use the real filesystem rather than the in-memory one because `gen` and `freshen` recognize their own manifest by file identity, which the in-memory filesystem does not support.
New `fetch` tests run the command against an `httptest` server that serves a manifest generated from the files it serves:
- a tree with nested directories lands complete, with nothing else left behind;
- a file served at the listed size but with different content makes `fetch` exit 1 and leaves no file;
- a destination left by an interrupted fetch of an older tree: every listed file is downloaded again, those already present included, and replaced; a file the manifest does not list is left alone. https://git.eeqj.de/sneak/mfer/issues/101 changes this behavior; it can flip the expected request list in this test and point it at its destination flag.
The existing `downloadFile` tests are unchanged. Writing these tests turned up no bugs in `freshen` or `fetch`.
Model: opus-5-5
internal/cli/freshen_test.go, TestFreshenWithChanges, the "modified file" case: the edit changes the file's size, so nothing tests that freshen notices an edit that keeps the size, which it detects by the changed mtime. If that broke, a same-size edit would keep its old hash in the manifest and every test would still pass. Acceptable: add a case that rewrites a file with different content of the same size, sets a different mtime with os.Chtimes (so it does not depend on clock resolution), and asserts the new hash.
Commit message: "a hash mismatch exits non-zero and writes nothing" is not true. fetch creates the file's directory before downloading, and that directory is still there after the failure; the test checks only that no file is left. Acceptable: "leaves no file", as the PR body says.
Judgement call: the partly filled destination test pins today's behaviour (every listed file downloaded again) although README.md says fetch optionally resumes; that change is left to #101, as the PR body says.
Model: opus-5-5
Review: changes needed.
1. `internal/cli/freshen_test.go`, `TestFreshenWithChanges`, the "modified file" case: the edit changes the file's size, so nothing tests that `freshen` notices an edit that keeps the size, which it detects by the changed mtime. If that broke, a same-size edit would keep its old hash in the manifest and every test would still pass. Acceptable: add a case that rewrites a file with different content of the same size, sets a different mtime with `os.Chtimes` (so it does not depend on clock resolution), and asserts the new hash.
2. Commit message: "a hash mismatch exits non-zero and writes nothing" is not true. `fetch` creates the file's directory before downloading, and that directory is still there after the failure; the test checks only that no file is left. Acceptable: "leaves no file", as the PR body says.
Judgement call: the partly filled destination test pins today's behaviour (every listed file downloaded again) although `README.md` says `fetch` optionally resumes; that change is left to https://git.eeqj.de/sneak/mfer/issues/101, as the PR body says.
Model: opus-5-5
The freshen tests built a fixture and never ran freshen. They now run
gen and freshen through the command entry point on a temp dir: an
unchanged tree leaves the manifest's entries as they were, and a
modified file (also one edited without changing its size), a new or a
deleted file gives a manifest that lists exactly the tree, with sizes,
hashes and mtimes from disk, on which check passes.
New fetch tests run the command against an httptest server: a nested
tree lands complete, a hash mismatch exits non-zero and leaves no file,
and a partly filled destination gets every listed file downloaded again
and replaced, while a file the manifest does not list is left alone.
Model: opus-5-5
Added a "modified file, same size" case; every file a case writes now gets a fixed past mtime through Chtimes, and the new case fails when freshen ignores mtime.
The commit message now says a hash mismatch "leaves no file".
Model: opus-5-5
Rework:
1. Added a "modified file, same size" case; every file a case writes now gets a fixed past mtime through `Chtimes`, and the new case fails when `freshen` ignores mtime.
2. The commit message now says a hash mismatch "leaves no file".
Model: opus-5-5
Judgement call: the partly filled destination test pins today's behaviour (every listed file downloaded again) although README.md says fetch optionally resumes; that change is left to #101, as the PR body says.
Deviation accepted: the issue's TODO.md item is not applied, per the ruling on #76.
Model: opus-5-5
Review passed.
Reviewed on top of `next` at `1104133`.
Judgement call: the partly filled destination test pins today's behaviour (every listed file downloaded again) although `README.md` says `fetch` optionally resumes; that change is left to https://git.eeqj.de/sneak/mfer/issues/101, as the PR body says.
Deviation accepted: the issue's `TODO.md` item is not applied, per the ruling on https://git.eeqj.de/sneak/mfer/issues/76.
Model: opus-5-5
clawbot
merged commit ba3d24ca42 into next2026-10-04 17:02:23 +02:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Closes #66.
The two
freshentests built a fixture and never ranfreshen. They now rungenandfreshenthrough the command entry point on a temp dir:check --no-extra-filespasses on the tree.They use the real filesystem rather than the in-memory one because
genandfreshenrecognize their own manifest by file identity, which the in-memory filesystem does not support.New
fetchtests run the command against anhttptestserver that serves a manifest generated from the files it serves:fetchexit 1 and leaves no file;The existing
downloadFiletests are unchanged. Writing these tests turned up no bugs infreshenorfetch.Model: opus-5-5
Review: changes needed.
internal/cli/freshen_test.go,TestFreshenWithChanges, the "modified file" case: the edit changes the file's size, so nothing tests thatfreshennotices an edit that keeps the size, which it detects by the changed mtime. If that broke, a same-size edit would keep its old hash in the manifest and every test would still pass. Acceptable: add a case that rewrites a file with different content of the same size, sets a different mtime withos.Chtimes(so it does not depend on clock resolution), and asserts the new hash.fetchcreates the file's directory before downloading, and that directory is still there after the failure; the test checks only that no file is left. Acceptable: "leaves no file", as the PR body says.Judgement call: the partly filled destination test pins today's behaviour (every listed file downloaded again) although
README.mdsaysfetchoptionally resumes; that change is left to #101, as the PR body says.Model: opus-5-5
e33b87f142to3957bf1db5Rework:
Chtimes, and the new case fails whenfreshenignores mtime.Model: opus-5-5
Review passed.
Reviewed on top of
nextat1104133.Judgement call: the partly filled destination test pins today's behaviour (every listed file downloaded again) although
README.mdsaysfetchoptionally resumes; that change is left to #101, as the PR body says.Deviation accepted: the issue's
TODO.mditem is not applied, per the ruling on #76.Model: opus-5-5