Multiple undo again...

[Jason Harris]

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

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

Yes. Exactly!

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

Ahhh... Thanks. But sorry what I was planning to do was:

something like for initialization:

export HGDIRNAME='.hgbackup'
hg init
hg addremove *
hg commit -m "initialize undo / redo"

Then when I needed to backup something like:

export HGDIRNAME='.hgbackup'
hg addremove *
hg commit -m "do a backup step"

So where in this process should I do the cp -al

Cheers & Thanks,
  Jas