Add Plan Atomic Commit, and reverse Write Durability's recommendation The durability page landed on a journal plus signal blocking, and treated RCS's temp-file-and-rename as the expensive option. It was missing the fact that decides the question: RCS rewrites the whole ,v because it stores HEAD first, so a commit shifts everything after it. We store HEAD last, so the unchanged part is a prefix -- copied as raw bytes, no parsing, no re-serialisation. That removes both objections at once, the O(file) cost (fsync dominates at wiki scale) and the bit-flip exposure of §6. So the new page is what was built, and §8 of the old one now says it was overturned rather than quietly disagreeing with the code. The journal and the signal blocking are dropped: with no write over live data there is nothing to undo and no Ctrl-C window. The page also records where the plan was wrong -- sendfile is Linux-only for file-to-file, abspath does not resolve symlinks, and the flush it argued for turned out to be unreachable -- since those are the parts worth remembering.
Add Write Durability: what survives an interrupted commit Collects the crash-safety analysis: an RLIMIT_FSIZE sweep mapping where an interrupted commit() leaves the file, what is still recoverable from the working file plus an intact delta, and how RCS, CVS, git and Mercurial each avoid the problem -- read out of their sources rather than recalled. Two findings run against the obvious framing. RCS is a hybrid, storing trunk revisions as reverse deltas and branch revisions as forward deltas. And RCS's whole-file rewrite, which buys it atomicity, is the worse choice under flaky memory: every commit passes the entire history through RAM, and rename() then installs any corruption atomically over the last good copy, with no checksum anywhere to notice.