[darcs-devel] store rebase patch at the repo layer

[Ben Franksen]

A few days ago I was deep into refactorings of the prim patch interfaces
in order to get prims with identities into the system. As usual I was
annoyed by the needless complications that arise because of the mixing
of normal patches with the rebase patch. So I stopped my work and
started to fix that problem on a clean copy, once and for all. I had
tried that before and had failed miserably, but this time I made it: I
am more or less done with it and will soon send patches (but not screen
them yet).

It wasn't as hard as I imagined it to be. I guess I succeded this time
because (1) I first added the new variant as an addition and only then
eliminated the old way, and (2) I had made lots of refactorings to the
repo layer in the meantime so that it is now cleaner and easier to work
with.

The interface between rebase and the rest of the repository is in fact
pretty simple and elegant: there are exactly four functions in
D.R.Hashed which are affected, and the changes are pure additions:

* tentativelyAddPatch_ now also modifies the rebase patch with a call to
removeFixupsFromSuspended.

* tentativelyRemovePatches_ now also modifies the rebase patch with a
call to addFixupsToSuspended.

* revertRepositoryChanges now also copies an existing rebase patch to
its tentative version; if that fails because there is none, an empty
rebase patch is created and we try again.

* finalizeRepositoryChanges now also uses renameFile to move the
tentative rebase patch to the normal rebase patch.

The code in D.R.Rebase is hugely simplified. The rebase command itself
is changed in a pretty systematic manner, replacing retrieval and
storage of the rebase patch from/to the head inventory with calls to
read or write the (tentative) rebase patch. Darcs.Patch.Rebase is fully
obsolete and can be deleted and similarly for Darcs.Patch.Named.Wrapped.

So much for the good news.

The bad news is that we can no longer handle a repo where an old-style
rebase is in progress. And, of course, an older version of darcs cannot
properly update the rebase patch in a new-style repo with a rebase in
progress, so we must forbid that. But how? The only way I can see is to
mark the repo as rebase-in-progress, as for old-style rebase, and then
let the old darcs fail when it doesn't find the rebase patch. Not very
friendly but workable.

For teh other direction, I think it would be possible to re-add minimal
support for reading old-style repos with a rebase patch mixed in,
without carrying around too much baggage in the form of obsolete code. I
am thinking about a 'rebase upgrade' or perhaps 'convert rebase' command
that can read such a repo, commute the rebase patch to the end, remove
it and then store the remaing patches and the rebase patch in the new style.

Cheers
Ben