Data loss and Undo (again)

[Kurt Granroth]

I think I may need to do some test timings on this :-)

My intuition is that a clone (or rsync --link-dest) would be 
*significantly* faster than an 'hg init && hg add && hg commit' for any 
large-ish repository.  That's because the clone/link-dest would be 
*mostly* just creating hard links while the add/commit would have to 
package up many megabytes worth of data.

Unless I'm missing something...

On 5/22/10 5:45 PM, Jason Harris wrote:
>
> On May 23, 2010, at 1:39 AM, Kurt Granroth wrote:
>
>> I like the concept quite a bit.  I can't count the number of times I wanted a series of undo steps.
>>
>> How about this, though; just auto-clone a (user settable) number of backup repositories for any substantial action.  Something like:
>>
>> hg clone .hg .hg-20100522T16:34:15
>> hg whatever-may-need-to-be-undone
>> hg clone .hg .hg-20100522T16:35:10
>> hg whatever-may-need-to-be-undone
>> hg clone .hg .hg-20100522T16:40:30
>> hg whatever-may-need-to-be-undone
>> oops.. i didn't mean to do those last two operations
>> mv .hg .hg-20100522T16:40:31
>> hg clone .hg-20100522T16:34:15 .hg
>>
>> If not 'hg clone' then 'rsync --link-dest=.hg' or similar.
>>
>> Each of the undo repos would take minimal extra hard drive space since they would be mostly hard links.  You could then have undo and redo for an arbitrary amount.
>
> Thanks for the suggestion! I thought of something like this but unfortunately the clone takes too long for even moderately sized repositories, whereas the delta save from the previous save is really quick. But thanks for the suggestion...
>
> Cheers,
>    Jas
>
>
>
>> On 5/22/10 9:23 AM, Jason Harris wrote:
>>> Hey there,
>>>
>>> I sent this a couple of days ago and heard a deafening silence in response to it... It goes to the heart of the issue about data loss through use of MQ or through other means, and possible ways to version the whole archive. Doesn't anybody have any comments on it? Are there better ways to do this, etc? Are there core plans for such a thing? I would love to know now before I implement this in MacHg...
>>>
>>> Cheers&   Thanks
>>>    Jason
>>>
>>>> Hi,
>>>>
>>>> Following the discussion about Git vs Mercurial and some users having lost data through trying to do tricky things... I have though for MacHg for a while now that it would be really nice to support undo. I can imagine this would be true of many other GUI clients as well. Ie thought about doing the following:
>>>>
>>>> Initializing the normal repository.
>>>>
>>>> Then to initialize undoable operations I would do the following:
>>>>
>>>> mv .hg .hgdata
>>>> hg init
>>>> hg addremove *
>>>> hg commit -m "undo initilization"
>>>> mv .hg .hgbackgup
>>>> echo ".hgbackup">>   .hgignore
>>>> mv .hgdata .hg
>>>>
>>>>
>>>> Then when I am about to do an operation which I want to be undoable, I would do:
>>>>
>>>> mv .hg .hgdata
>>>> mv .hgbackup .hg
>>>> hg addremove *
>>>> hg commit -m "undo operation ${OPERATION}"
>>>> mv .hg .hgbackup
>>>> mv .hgdata .hg
>>>>
>>>> Ie then I could have operations to undo / redo operations so it restores things to their *exact* states as they were.
>>>>
>>>> At periodic times I could throw out the .hgbackup directory and start over.
>>>>
>>>> Of course this makes all operations basically twice as slow as they would otherwise be. Possible more in some circumstances...
>>>>
>>>> First question: Is there a better way to do this? (I have played with bundling changes but I think it could get a little tricky...)
>>>> Second question: If this is horribly inefficient would it be possible to make it efficient by modifying Mercurial (some sharing of file's etc...)
>>>> Third question: Should something like this be more ingrained in the core which can be **optionally** turned on?
>>>>
>>>> Thanks,
>>>>   Jason
>>> _______________________________________________
>>> Mercurial mailing list
>>> Mercurial at selenic.com
>>> http://selenic.com/mailman/listinfo/mercurial
>>
>> _______________________________________________
>> Mercurial mailing list
>> Mercurial at selenic.com
>> http://selenic.com/mailman/listinfo/mercurial
>