Multiple undo again...

[Jason Harris]

On Jun 4, 2010, at 7:33 PM, Martin Geisler wrote:

> Jason Harris <jason at jasonfharris.com> writes:
> 
>> 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
> 
> So it seems that the history in the .hgbackup repository wont mean
> anything?

Exactly!

> It will just be a sequence of snapshots and I guess you're
> only using Mercurial for this to have some automatic compression?

Exactly! It could / will be thrown out periodically. (Actually like a log file it will probably be moved to a backup and then be dumped at some stage in the future automatically.) Of course if things get really stuck or tricky then the user can fire up Mercurial on the .hgbackup and navigate in a totally familiar way...

> Is the 'hg addremove' step to save unversioned files?

Exactly!

> I'm not sure why
> you need to save those since Mercurial should not touch them as shown in
> this example:
> 
>  % hg init
>  % echo foo > a.txt
>  % hg add
>  adding a.txt
>  % hg commit -m 'add a.txt'
>  % hg remove a.txt
>  % hg commit -m 'remove a.txt'
>  % echo bar > a.txt
>  % hg status
>  ? a.txt
>  % hg update 0
>  abort: untracked file in working directory differs from file in
>  requested revision: 'a.txt'

Is that guaranteed for absolutely every file? (I still look at .hgignore and ignore those files, its just the unknown files I backup.)

Ie is it totally guaranteed that there are no extensions or other things which write to files which are not versioned controlled? eg some .hgrebase state or something? some bfiles extension which pulls things directly into a patch, etc. Or for another example I can imagine a file being directly imported into a patch without ever hitting something which is a plain old versioned Mercurial file.

Thus I wanted to be sure that the undo command, really absolutely in a totally robust way undid everything and took you back to exactly where you where before doing the change(s)... Or at least thats the goal as I see... :)

Implementing it the way I am is likely just an implementation detail. Ie if I were a core Mercurial developer I would likely know a better way to do this. eg the 'hg commit -m "do a backup step"' has to scan the whole directory when core Mercurial should already know what is about to change. So the scan of the whole directory before the commit should only happen once (not once for the backup and once for the main command...) But you get the idea.

(In fact in my code I use commit --addremove --message "do a backup step" which then just has one scan for addremove and commit instead of the two separate scans.)

Of course given Matt's "No thanks" on the whole undo idea I doubt there will ever be a core Mercurial solution to this.

(BTW  I have even though of sacrilegiously using git to handle such a thing nicely. Ie could I version the mercurial repository nicely using git... (The irony...))


Cheers & Thanks,
  Jas