[darcs-devel] What should be in a branch?

[Ben Franksen]

The state we currently maintain for a repository is:

- the head inventory (incl. pristine hash, _darcs/hashed_inventory)
- the pending patch (_darcs/patches/pending)
- the rebase patch (_darcs/rebase)
- the unrevert bundle (_darcs/patches/unrevert)

(I am not considering the index and the patch index here because they
are only caches and can be restored from the above data and the working
tree.)

How much of that do we want to associate with a branch?

The traditional way to work with "branches" in darcs is to make a clone.
This means that a "branch" has a full copy of all the per-repo state as
listed above.

Branches in git are simpler. Roughly speaking, a branch in git is a name
for a leaf (HEAD) commit; in darcs this corresponds to a head inventory,
together with its pristine. Everything else exists either at most once
per repo (rebase, pending/staging area) or is not tied to a branch
(stashes, roughly corresponding to unrevert). For instance, you cannot
switch to another branch if there are pending changes that conflict with
the new branch (like, if you have staged changes to a file and want to
switch to a branch that doesn't have that file, you get an error).

If we stored all of the repo state in hashed form, then it would be
straight-forward to couple it with the head inventory of a branch, so we
could have multiple pending, rebase, and unrevert states, one for each
branch. Which means that switching to (checkout) another branch can be
done any time without loosing information. However, storing all repo
state in hashed form is a disruptive change affecting a lot of the
Repository and UI layer code, see discussions elsewhere.

Would it be a great loss if we followed the git way, that is, have only
one pending and one rebase per repo and not one per branch?

Pending changes can be (temporarily) recorded and put on a new branch.
Similarly, a rebase in progress can be reified and put on a new branch.
We could offer the user to do these things for them when they want to
checkout a different branch, prompting the user for a branch name. For
pending, we could also emulate git by trying to transfer
(record+pull+unrecord) pending to the new branch and fail only if we get
conflicts or if pending depends on patches not contained in the other
branch.

Cheers
Ben
-- 
I would rather have questions that cannot be answered, than answers that
cannot be questioned.  -- Richard Feynman