Correct the diff-engine backend story, and review the rest against source Diff Engines had it backwards. It said StreamSequenceMatcher was the only engine on the commit path and the Cython Myers matchers existed only for benchmarking. matchers.py resolves dmp_cython -> ses_cython -> stream at import, and ACTIVE_BACKEND is dmp_cython wherever the extensions built: the Cython matcher is the default and StreamSequenceMatcher is the fallback. A reader following the old page would have looked in the wrong place for both correctness and performance questions. The same claim was duplicated in Source Code Map, which grepping the corrected phrases turned up. The page also presented three different measurements as one story: an unsourced "15-26x", the parser page's regex-vs-no_regex number, and that page's estimate for a Cython parser port that was never done. Replaced with a benchmark run recorded with its parameters. Wiki Backend Design still described the in-place tail rewrite as how commits work, which its storage comparison rests on. Annotated in place rather than rewritten, since the measurements behind it are unaffected -- the benchmark scripts run on BytesIO -- but the "filesystem is native" reasoning now fits the Large Object adapter better than the filesystem. Adds a flowchart of the commit write path, where the two backends diverge and only one of them overwrites live data, and the two design pages to the English Home, which had only the Korean one.
Refresh the core pages against source, and record the atomic commit The six core pages had not been touched since the first ingest, and the format has moved under them. The commit path was still documented as an in-place seek/write/truncate over the live HEAD, which is now only what the memory and caller-stream backends do; a file-path store builds a temp file and renames over it. The binary field was still ";base64," when the tag is one of raw/base64/base85, escaping applies unconditionally, and the stored length counts post-escape bytes. The '@' parity rule that makes the framing decidable in both directions was written down nowhere. Also adds gitpatch.py and matchers.py to the source map along with get_bytes() and durable, and the two CLI flags that had no page: srcs_commit --encoding and srcs_diff --binary. Every command on the CLI page was re-run before being written down, which turned up an error present since the first ingest: the srcs_diff examples passed the .srcs path, but that tool resolves the tracked file name and would have gone looking for my_doc.txt.srcs.srcs. Fixed, and the inconsistency behind it -- three tools want the .srcs path, two want the tracked file, one takes either -- is now stated rather than smoothed over.
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.
Re-measure 5-1 after fixing commit()'s return value The old numbers came from a run where commit() returned the whole serialized stream on in-memory instances, so the benchmark stored a stream copy in the version column and made design B look heavier than it is. Design B is flat, as expected; retract the "B gets slower than A" claim. The conclusion that a single BLOB column suffices at wiki scale is unchanged.
Lead Wiki-Backend-Design with the empirical conclusion, not the pre-benchmark theory Sections 4 and 6 still framed "one BLOB column per page" as structurally inferior to per-revision row normalization, even though the §5 benchmarks showed the opposite: column storage is fine at normal wiki scale (fsync dominates, waste ratio ~1.08x) and row normalization measured slower. Reorder and rewrite so the actual finding leads instead of the leftover theoretical concern. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LatyexR95wdY5YvefRKmys
Add full wiki: system overview, source map, storage format, diff engines, CLI tools Bilingual pages (Korean + -en English counterparts) covering the core architecture, plus the Wiki-Backend-Design notes moved over from the main repository's docs/. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01LatyexR95wdY5YvefRKmys
Initial Home page