temporary changesets?

[Brendan Cully]

On Tuesday, 03 July 2007 at 22:38, Chris Quenelle wrote:
> 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?

Have you seen the imerge extension?

http://www.selenic.com/mercurial/wiki/index.cgi/ImergeExtension