Rethinking mq and pbranch now we have rebase

[Peter Arrenbrecht]

Folks, maybe clever use of rebase could lead to a new approach to what
is currently addressed by mq and pbranch.

We could keep the master copy of the tentative changes in actual
changesets instead of in patch files (mq) or branch diffs (pbranch).
So on top of qparent, we'd have csets qbase..qtip. qgoto then simply
becomes update qN, where qN is the n'th changeset in the queue.

The trick is how to handle qrefresh. It becomes, essentially:

  $ hg diff --rev q(N-1) >/tmp/the-changes  # take diff against parent
  $ hg update -C q(N-1)  # go back to parent
  $ hg import -m "text of q(N)" /tmp/the-changes

So here we've forked (which I shall use as a term for lightweight
branching) a new version of qN. Let's call the old version qNa and the
new one qNb. q(N+i) are still based on qNa. So all that remains is to
rebase them onto qNb to get our queue back into proper condition. Then
we can strip qNa.

Another approach is to simply commit as a new cset on top of qN, then
rebase the q(N+i) on top of this, then fold qN with the new cset using
histedit.

Inserting, deleting and folding patches would also just boil down to
proper use of rebase and histedit. Though I do believe rebase would
need some additional love to handle rebasing onto ancestors and such.

Of course, this whole dance would have to be encapsulated by a set of
q commands.

But maybe the better terminology for this approach would be tentative
changes, or some such, instead of a queue.

Advantages over mq:

 * Feels more hg-ish than mq to me.
 * Always clearly defined which in-flight cset applies against which parent.
 * Uses built-in merge logic, not patches and rejects.
 * Uses normal log/glog to view even unapplied patches.
 * Could keep old history by using rebase --keep and then closing the
dangling heads.
 * Could, in principle, support forks and joins within the queue.
 * Cloning repos with queues is trivial.

Disadvantages:

 * Reordering the series could be harder, but maybe histedit already
handles this today.
 * No qguard.

Advantages over pbranch:

 * Far simpler conceptually.
 * No clutter in the changelog.
 * Can use plain tools to view changes (no pdiff, pemail, etc.).
 * Can still use hg diff -r qNa:qNb to review changes between versions
of "patches" if history is kept.

Disadvantages:

 * Haven't thought through how the rebase scheme fares for
collaboration on patches yet. Could be that pbranch is superior here
(see http://www.arrenbrecht.ch/mercurial/pbranch/collab.htm).

We might want to provide a guard against such tentative changes
getting pushed or pulled without people realizing what they are doing
(as would be desirable for mq and pbranch today, too).

Key needs:

 * Improved rebase
 * Naming scheme for easy addressing of tentative changes (bookmarks?)
 * New commands to automate some of the dances

Thoughts?
-parren