experiments with multi-rev undo

[Andrea Arcangeli]

On Fri, Jul 08, 2005 at 02:09:45PM -0700, Matt Mackall wrote:
> dependent on undo. Undo breaks all sorts of assumptions of the model

I don't see this breakage of the assumptions.

Assume I make a backup of the .hg directory in a tar.gz, then I keep
checkin in stuff two times, and then I want to go back of two revisions,
I just delete the .hg directory and I unpack the old .hg and there we
go, that's the the "two level" undo. It'll keep working fine with all
other forstest of trees on the net, no collisions at all, others can
again pull from my tree like if somebody cloned it before the two
commits.

I don't see this breakage and what's wrong about the model that prevents
a multiple undo, when a tar.gz will obviously do the two level undo just
fine. The one level undo just looks an hack.

I don't see many cases where a one level undo is useful, if you do a
real development mistake with the editor, it's much quicker and simpler
to execute two commits, than to use undo and to update the tree.
I.e. I only see it useful to remove heads, which it can't do right now.

Perhaps the problem you're talking about is parallelism between a net
export of the tree, and a local undo execution, but even that is fixable
trivially with a single flock, but it's not even needed, undoing
net-exported trees sounds pointless. I assume people works on a local
repository, and then it pushes it to a remote visible tree on some
server (not on the workstation), and let others pull changes from the
exported tree. The exported tree never needs to do the undo.

The multiple-levels undo (i.e. the head removal up to the first common
ancestor) doesn't need to be cheap or work in O(1), it just needs to
take less space than a .tar.gz backup of the .hg directory after each
backup ;). Chris's work seems very promising in that direction ;).

Thanks.