Multiple undo again...

[Martin Geisler]

Jason Harris <jason at jasonfharris.com> writes:

> On Jun 4, 2010, at 3:39 PM, Martin Geisler wrote:
>
>> Jason Harris <jason at jasonfharris.com> writes:
>> 
>> 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?

Yes, you marks all the heads reachable from A as dead. There is a
problem with this: if you have X -- Y -- A -- B and mark B dead, then
you need to know that X and Y are still alive.

Perhaps one could track the living heads as a kind of bookmarks...?

> 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?

Sure, they would need to change so that they don't remove history but
mark it dead instead. I've patched mercurial.repair.strip and that was
enough to make 'hg strip' and 'hg qrefresh' do what I wanted.

Btw, a repository looks quite strange after doing 'hg qrefresh' a couple
of times with our patches:

  % hg glog
  o  changeset:   6:db0d4f6f179f
  |  tag:         tip
  |  parent:      1:f4f8467152bc
  |  user:        Martin Geisler <mg at aragost.com>
  |  date:        Fri Jun 04 16:25:41 2010 +0200
  |  summary:     [mq]: patch
  |
  | o  changeset:   5:dc4f3b1ec1c3
  | |  user:        Martin Geisler <mg at aragost.com>
  | |  date:        Fri Jun 04 16:25:41 2010 +0200
  | |  summary:     Killed by strip
  | |
  | o  changeset:   4:3ea87a01df6a
  |/   parent:      1:f4f8467152bc
  |    user:        Martin Geisler <mg at aragost.com>
  |    date:        Fri Jun 04 16:25:32 2010 +0200
  |    summary:     [mq]: patch
  |
  | o  changeset:   3:e27c8e9f31b3
  | |  user:        Martin Geisler <mg at aragost.com>
  | |  date:        Fri Jun 04 16:25:32 2010 +0200
  | |  summary:     Killed by strip
  | |
  | o  changeset:   2:8b619b27ac61
  |/   user:        Martin Geisler <mg at aragost.com>
  |    date:        Fri Jun 04 16:25:11 2010 +0200
  |    summary:     [mq]: patch
  |
  @  changeset:   1:f4f8467152bc
  |  user:        Martin Geisler <mg at aragost.com>
  |  date:        Fri Jun 04 16:24:32 2010 +0200
  |  summary:     b
  |
  o  changeset:   0:a91e09c17f1c
     user:        Martin Geisler <mg at aragost.com>
     date:        Fri Jun 04 16:24:20 2010 +0200
     summary:     a

For this to work, we would have to hidde the killed changesets from log
and glog.

> 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...

It will work in the sense that we're only adding stuff to the graph.

> 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...)

Well, a clone will already use hardlinks, but you're also talking about
making backups of the other files in .hg/ right?

You can just hardlink all files (cp -al). I just tested with mq, and it
will break the hardlink before it modify .hg/patches/status. As long as
all the code is using the util.opener class for file access, then you
will be safe.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://aragost.com/mercurial/