Module in_memory 

In-memory MemBackend — the writable, filesystem- and git-free companion to the folder backend.

The mem lives entirely in RAM: committed entity bytes, the staged mutation buffer, the provenance log, and the per-mem config all sit on one Mutex-guarded [State]. Creating a backend provisions nothing on disk; dropping it releases the mem with no residue to clean up. Built to serve ephemeral per-session playground mems the session server spins up and tears down on demand.

Why model on the folder backend

The folder backend (super::filesystem::FilesystemMemWriter) is the closest sibling: it buffers mutations until commit, mints a synthetic history-free commit-id, and keeps a sidecar provenance log. This backend mirrors that contract one-for-one — same buffer-then-commit semantics, same read-sees-pending ordering, same path-rejection rules (it reuses [super::filesystem::normalise_rel_path]), same synthetic commit-id ([super::filesystem::make_commit_id]) — so the engine produces identical engine-level outcomes regardless of which of the two serves a mount. The only difference is the substrate: a HashMap in RAM instead of a directory tree on disk.

No durable history

Like the folder backend, this one has no commit history: MemBackend::current_head inherits the trait default returning Ok(None) rather than fabricating a git-like head, and commit_with_expected_parent inherits the default that ignores the pin and delegates to commit. Optimistic locking is unaffected — the engine enforces the expected_hash CAS above the backend, so a stale hash trips the same HASH_MISMATCH here as on any other backend.

Structs

InMemoryBackend

Writable mem backend whose entire state lives in memory. See the module docs for the contract it shares with the folder backend.