Multiple undo again...

[Jason Harris]

On Jun 4, 2010, at 11:55 PM, Martin Geisler wrote:

> Jason Harris <jason at jasonfharris.com> writes:
> 
>> 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...
> 
> Mercurial wont be a good container for the backups since you cannot
> delete the oldest backup while keeping the younger backus intact.

But generally when you are done with the whole backups you just throw them out. Ie if you quit photoshop or Autocad, or Word, you can't undo your previous changes. So "throwing out" the undo log at various stages, isn't so bad.


>>> 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.)
> 
> There's no guarantees here, only good intentions from Mercurial's side
> that it tries not to mess with your untracked files :-) By the way, have
> you not tried out an example like the one I gave before you began this
> huge thread?

Yep I did :) Actually for undo I do a hard undo of update -C, so it will really undo all your changes. Of course if you loose something in the undo, you can just redo the change to get back your lost changes :)

> So, as I understand it now, your goal is to make a backup copy of
> untracked files because you are afraid that something will change them.

Its my goal in so far as I want multiple undo. Of course the desire is to have this as fast as possible, as robust as possible, and as small as possible. This is just the only way that I, as someone who doesn't know the internals was trying to get it...

> I would rather fix whatever it is that overwrites the untracked files,
> but lets say we cannot do that because people keep making wacky
> extensions...

Well thats the worry. I mean right now there are all the patch files which are not tracked (unless you also version them). Then there is the rebase state, which is also not tracked, then there is the histedit state which would also not be tracked. Maybe that list is exclusive, and no other extensions will write anything which we have to remember to backup and have some undo support in there for, but it struck me as rather than trying to catch every extension which does something it might be better for a guaranteed always robust, general solution. But then again if it strikes you as best to try and get these extensions to somehow backup their state as the best way then since you know the internals far better than me, I'll go with your recommended way to do multiple undo... :)


> I think this was the point where you confused us all by talking about
> using Mercurial for this instead of just saying that you'll copy the
> untracked file into directories named something like ~/.machg/backup-1,
> ~/.machg/backup-2, ~/.machg/backup-3, etc...

Well of course backup-2 is just slightly changed from backup-1, and backup-3 is just slightly changed from backup-2. This of course then describes a simplified version control, and Mercurial is very good at version control.


> That would have been much easier to comment on. We could then have told
> you that Mercurial wont be a good tool because you cannot delete old
> history, as noted above.

But you delete the old history by throwing out the backups when you quit or decide you don't want them anymore (well actually move them aside like log files for a bit before you throw them out.) This is largely what I or others would do with junk clones. (ie clones we make in case something goes wrong...)

Again my goal was multiple undo & redo support. As I candidly said from the begining, I am sure there are better ways, and this was just one way I saw to get this functionality. I am keenly interested in a better way to get this functionality :)

Cheers & Thanks,
  Jas