[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SV: Feature request: unrevert

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: 2006-10-18 19:36:42 CEST

km@dfa.com wrote:
>
>
>
> Stefan Küng <tortoisesvn@gmail.com> wrote on 10/18/2006 01:04:00 PM:
>
>> But command line tools can still use the SHFileOperation() API which
>> makes use of the recycle bin.
>
> Of course they can ('start' does just that). But it's not expected
> behavior.
>
>>> Here's one way revert recycling can work:
>>>
>>> o User selects files to revert
>>> o Tortoise renames each file to a temporary name
>>> o SVN revert is called
>>> o If the revert fails, the renamed files are renamed back to their
>>> original names, overwriting any partial revert
>>> o If the revert succeeds, the new files are renamed to another
> temporary
>>> name. The original files are renamed to their original names and sent
> to
>>> the recycle bin. The new files are finally renamed back to their final
>>> names.
>> You're doing a *lot* of renames here. Which always means heavy disk
>> access, and disk access is slow. If you're dealing with big files (e.g.
>> large image files of several MB in size), you could slow down a revert
>> operation for several seconds.
>
> Speed of a rename has nothing to do with the size of the file. (It is
> affected by the number of other files in the same directory, but unless
> you're looking at hundreds of files, the total time is still
> insignificant.) Even if there are a lot of renames, they will be

That's not quite correct. You're right if you rename the file on the
same drive. But we'd have to use the temp folder to store those temp
files, and for many people the temp folder is on a different drive.
If we would rename the files in the same folder they are, we have a
problem finding a filename which doesn't already exist

> significantly outweighed by the amount of time it takes to copy the
> original file from the .svn directory. The average rename is still faster
> than the average copy of zero-length file (by a factor of 18x by my
> estimates, but those are probably skewed).
>
> In the failure case, we're doing two renames. In the success case, we're
> doing five (including the move to the recycle bin).

And that last move could take several seconds. You may have noticed that
if you delete a file in explorer it can take quite a while. Even longer
if the trash bin is 'full' (i.e. has already the size of its specified
limit, which usually is 20% of the size of the harddrive).
I sometimes have to wait a whole minute until a file is deleted (which
then reminds me to clean the trashbin - after that it's fast again)

> If you don't think everyone would want it, make it an option. But some of
> us really need it. It's royally painful to lose a week's work with a
> single click. That's the reason the recycle bin was invented.

A weeks work? In that case, I really recommend you create a branch for
your work and commit way more often. That's what branches are for!
Oh, and you requested an option:
http://tortoisesvn.net/request_for_new_options

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Oct 18 19:36:57 2006

This is an archived mail posted to the TortoiseSVN Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.