Multiple undo again...

[Jason Harris]

On Jun 4, 2010, at 3:39 PM, Martin Geisler wrote:

> Jason Harris <jason at jasonfharris.com> writes:
> 
> This sounds like something that belongs on mercurial-devel only.
> 
>> [...]
>> 
>> Now of course one might say "just be careful" when you do changes like
>> reordering changesets, collapsing them etc. But the thing is, I
>> *don't* want to be careful. I am likely thinking about a zillion other
>> things and I am using MacHg or Mercurial on "auto-pilot" I want to do
>> my changes and get back to what I was working on... A good system
>> should be forgiving and so allow me to mess up and recover if I did
>> mess up. Hopefully this is enough motivation to see why one wants
>> multiple undo and redo in a system.
> 
> Instead of keeping full clones around for backup purposes, how do you
> feel about my idea of simply leaving the "deleted" changesets around?
> 
> That is, when reordering
> 
>  A --- B --- C --- D
> 
> to
> 
>  A --- C' --- B' --- D'
> 
> we keep the old B, C, D around and mark them dead:
> 
> 
>  A --- C' --- B' --- D'
>   \
>    B --- C --- D --- <X>
> 
> Here X is a new changeset which has a bit of metadata that tells
> Mercurial to not push it anywhere[*].
> 
> Henrik and I (well, mostly Henrik) have been working on a set of
> patches that implements this:
> 
>  http://bitbucket.org/mg/dead-branches/
> 
> 
> [*] I think it would be nice if X are pushed to another repository if it
>    already has some of B, C, D -- that is if the topological branch
>    that X kills is already partyly pushed. Henrik does not like[**]
>    this automatic spreading of dead heads. He says its impolite to
>    spread corpses around automatically or something like that.
> 
> [**] My theory is that this is because he is not clever enough to
>     implement it... :-)


It sounds ok, butttt.....

What happens with mq operations, or strip operations, or histedit operations, will all this work nicely?

eg if I do a hg strip A,

then internally this would translate the strip command to just mark these changes as dead? Wouldn't that require changing the strip command, and the hist edit command, and the collapse command, and basically all the commands that do such things?

Also there are times when eg rebase does a merge instead of doing a rebase, I often have to strip these back, etc due to the Mercurial "tree" getting messed up, and try and do things again. Or maybe I do a merge and then undo it, would all this just work? With every extension that is out there at present? I kind of have my doubts...

Whereas it seems to me a complete parallel clone would be very simple and robust. Mercurial has this machinery more or less totally down and working.

In fact if there was some low level hook then likely there could be node sharing in any case so it wouldn't take up much space at all, and hopefully if this was tied in at a low level it would be quite fast since Mercurial would "know" which files it is about to modify and how. It just then tells the backup which files to clone / change and then its done. Thus the backup should take up very little space, and would catch "everything" and wouldn't have to hook into all the various commands. It should hopefully just tie into some core mercurial commands at a low level, of "am I about to change things?", if so backup these changes, then do the change...

Or at least this is the way it *seems* to me since I don't know the internals (it could very well be that what I am suggesting is quite difficult for technical reasons of which I am blissfully unaware...)

In the end of course I just want multiple undo support to be really robust and quick. Right now doing this through the introduction of a HGDIRNAME seems to work and is my best and most robust option. But of course I am totally willing to look at other options :)

Cheers & Thanks,
  Jas