Multiple undo again...

Martin Geisler mg at lazybytes.net
Fri Jun 4 16:55:49 CDT 2010


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.

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


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

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

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.

> [...]

-- 
Martin Geisler

See my Mercurial presentation: http://vimeo.com/11497288
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100604/39a0cea2/attachment.pgp>


More information about the Mercurial-devel mailing list