temporary changesets?

[Chris Quenelle]

It occurred to me a while back that you could use "temporary revisions" as a way
to replace the MQ extension with core hg functionality and a unified command set.
There was a discussion recently about how to deal with large complex merges and
I think that "temporary revisions" could apply there to.

Some people from the OpenSolaris project discussed the ad-hoc process they
used for cooperative merges.  You might have one person who is trying
to perform a merge, but who might not have been the primary engineer working
on either branch that's getting merged.  In that case, the "gatekeeper"
person doing the merge might merge some of the easy files, and then want
to hand off a partially merged area to someone else to study.

Mercurial was DESIGNED to allow multiple people to cooperate on making
complex changes to source code.  It really seems obvious that passing around
an NFS pathname pointing at a partially merged repository is wrong thinking.
I thought about this some more, and I started to think that logically
a merge operation was a combination of three different revisions, not
a combination of two revisions.  You could take all the time in the world
to craft a revision that you believe represents the merge between two
other revisions, you could get that third revision reviewed, then you could
finally "commit" the merge by telling mercurial that revC represented the
combination of changes between revA and revB.

Obviously simple merges would still want a process like todays where you
can do it all in one session, but it seems like fundamentally a merge
is a combination of 3 revisions.  BUT you really want to remove the
revision that represents the 'precommit' state, and only keep the
revision that is 'registered' as the official combination, where the
repository structure is updated to record the merging of the two branches.

So this brings us back to a desire to have temporary revisions.  It seems
simple enough in concept.  Any revision marked 'temporary' (and any revision
downstream of such a rev) would not put pushed or pulled by default.
You'd have to use a special option to force it to happen.  You'd also
want to support all the basic MQ features for pushing and popping revisions.

In a sense these are "uncommitted" revisions.

Ideas? Thoughts?  Could I create a page on selenic.com to record this idea?

I don't know that much about the details of MQ.  If there are things MQ can
do, but 'temporary revisions' can't do, I'd like to know more about it.

--chris