Proposal: backup hook, trash, and multiple undo

Dan Villiom Podlaski Christiansen danchr at gmail.com
Tue Jun 8 10:51:32 CDT 2010


On 8 Jun 2010, at 17:15, Matt Mackall wrote:

> On Mon, Jun 07, 2010 at 08:57:26PM -0400, Greg Ward wrote:
>> On Mon, Jun 7, 2010 at 10:23 AM, Matt Mackall <mpm at selenic.com> wrote:
>>> Jens' mention of the OS X trash can got me thinking about how we'd
>>> implement such a thing, and here's what I came up with:
>>> 
>>> Backup hook:
>>> 
>>> A standard hook called "backup" that gets called whenever a destructive
>>> operation gets called. It operates in a couple different modes:
>>> 
>>> type=file
>>> operation=rm|update|merge|revert|qdelete|...
>>> path=/path/to/file/being/clobbered
>> 
>> What's the common thread here? hg is deleting any file, or deleting a
>> file in the working copy, or deleting a file that isn't already saved
>> in a changeset somewhere?
> 
> File changes that could result in data loss.

I think it would be useful to distinguish changes which certainly result in data loss (rm, qdel, etc.) from changes which possibly result in data loss, such as merge and update. In my opinion, data moved to the trash should be considered semi-lost, as it's not uncommon to empty the trash without closely inspecting the data in there. Generally, I'd expect a ‘trash’ extension to affect deliberately destructive operations, and I'm not sure users would expect e.g. ‘revert’ to put the original in the trash.

I'd suggest two operations; one used as a result of intentionally destructive operations and one used for other commands, where destructive behaviour is a side-effect. The former would be used in cases where the file is currently deleted, and the latter for cases where a *.orig file is created.

>> I have a hard time seeing "hg merge" and
>> "hg qdelete" being equally destructive: the only time "hg merge" can
>> irreversibly discard data is if you run it with -f.  (Right?)  But
>> qdelete is irreversible by default -- much more dangerous.
> 
> merge can mangle files that get merged, which is sometimes just as
> good as deleting them. We currently store a .orig file (which clobbers
> any existing .orig file), this would also hand off that file to the
> backup hook.

I don't think it would be safe to only store these files in the trash; they might be useful for conflict resolution, and could be considered a useful notification to the user that the result of the merge may be unexpected.

> (Typical trash cans also clobber identical files.)

For what it's worth, the Mac OS X implementation avoids this by appending a timestamp to the trashed files. I'm not sure, but I think the timestamp used is the last modified date of the file or directory.

--

Dan Villiom Podlaski Christiansen
danchr at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1943 bytes
Desc: not available
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20100608/13863952/attachment.bin>


More information about the Mercurial-devel mailing list