This is from David Roundy's msg5797 on issue992:

Anyhow, this should be combined with a safety refactor which would ensure that
the _darcs/hashed_inventory is only read once:  we should store its contents in
the Repository data structure, so we can't accidentally mix two views of a
remote repository during one command.  I don't think we currently make this
mistake, but it's troubling that we could.  

David goes on to comment on how this would fit into issue992:

Once this refactor is done (which
means that we'd read _darcs/hashed_inventory when first identifying the
Repository), we can easily make darcs read _darcs/inventories/xxx instead, if
the URL has some fancy format that includes a hash value.  Or if a file with
that hash isn't present in _darcs/inventories/ we'd look at
_darcs/hashed_inventory to see if that has the right hash.  This feature will
enable self-authenticating URLs, albeit URLs that only describe a specific version.

Petr says this is already done as part of his adventure refactor:
http://irclog.perlgeek.de/darcs/2010-09-06#i_2790255

I think this was never ported from adventure to HEAD, so marking it as
"needs-implementation" again.

I would extend the scope of the proposal, following Petr's observations:

> But the actual motivation for that was getting rid of the tentative
files, which are superfluous and, to some extent, dangerous.
> You don't need to dump the intermediate states to disk, really.
> And they are dangerous because the API allows direct access to both
non-tentative and tentative stuff.

So the scope would be:

* always read hashed_inventory once
* never write tentative_hashed_inventory, tentative_pristine and maybe
pending.tentative, instead keep them in memory.

That would reduce Darcs' filesystem IO footprint, which is welcome
especially in cases like repositories in sshfs or dropbox.

Abandoning the tentative files and instead keeping them in memory sounds
like a viable alternative to my idea of tracking the transaction state
in a type witness.

However, must make sure that we do not accidentally keep the whole repo
in memory, only the head inventory.

Another obvious idea is to abandon hashed_inventory (including the
tentative version). Instead, always store the head inventory hashed and
keep only its hash in a file under _darcs. It may be difficult to make
this change in a backward compatible way, though.

Looking at the code for writeTentativeInventory reveals that we already
store the _darcs/hashed_inventory (minus the pristine hash) inside
_darcs/inventories in standard hashed format. Thus we could compress
_darcs/hashed_inventory to a file that contains only the pristine and
inventory hash as e.g. _darcs/current_state. Reading this file, caching
the two hashes in the Repository token, and updating it whenever the
repo is modified would be cheap and could be done for each command. We
should be careful to write the parser for this file in a way that allows
future extensions of the format, e.g. for when we add versions or branches.

We must continue to write hashed_inventory, though, to remain compatible
with previous versions of Darcs. So here is my revised plan:

* always read current_state and pending once
* never write tentative_hashed_inventory, tentative_pristine, and
pending.tentative, instead keep them in memory as members of Repository
* on finalization, write hashed_inventory, pending, and current_state
each atomically by first writing to a temporary name and then renaming
(like we  already do for pending)

This move could be accompanied by adding a Repository witness for the
pending state (wP).

I am currently persuing the idea of making this change in a way that is
compatible with and prepares for future extensions regarding in-repo
branches.

The idea is to condense hashed_inventory and patches/pending into small
files that contain three hashes: the inventory hash, the pristine hash,
and the pending hash. This requires the current head inventory to be
hashed but apparently we already do that (see writeTentativeInventory).
We also need to hash pending, which we do not do yet.

These branch files live under a new directory _darcs/branches. The first
step adds only a single branch named "current". We read that file once
when we identify a repo, falling back to reading the old special files
if it does not exist, and creating the branch file if this is our local
repository. The Repository type is extended to contain the branch data,
consisting of the three hashes and the branch name. On finalization we
atomically write the branch back to disk (but we need to maintain the
old special files, too, for compatibility).

If we take care to make the format extensible (in a forward and backward
compatible way) we can add more hashes later, e.g. for the unrevert
bundle or the rebase patch, once these are converted to a hashable
format or uncoupled from the normal patches, respectively.

I much prefer this refactor over the idea of tracking transaction mode
in the types.

Okay, if this is a preparation for branches, then I want to get things
right. I made a conceptual mistake when I proposed a
_darcs/branches/current file.

So a named branch is a file under _darcs/branches named like the branch.
We need exactly one branch to be active ("checked out" in git terms).
How do we represent that? A simple solution is to maintain a copy of the
active branch file as _darcs/active_branch. We could also store just the
branch name in _darcs/active_branch (akin to a symbolic link); but that
doesn't fit well with the idea of introducing branches step-by-step:
we'd have the conjure up a name for the single branch in a traditional
single-branch-repo. So, for the first step we don't actually need the
_darcs/branches directory, just a single file _darcs/active_branch or
perhaps just _darcs/active.

The more I hack on this the more I like it.

This refactor turns the Repository API into something much more
functional in style than it used to be. While most of the functions
still return IO actions (because we have to read and write the hashed
store), we largely avoid /stateful/ IO: what we read and write is
determined by the hashes, so we don't actually modify state in a
semantic sense... except right at the end when we finalize the branch
data for comsumption by subsequent darcs commands. The whole "tentative"
vs. "recorded" distinction simply disappears.