I personally never use the recycle bin and would be
miffed at a performance loss to support it.
Small, regular commits are your friend.
Thanks,
Joseph
km@dfa.com wrote:
>
>
>
> Stefan Küng <tortoisesvn@gmail.com> wrote on 10/18/2006 01:36:42 PM:
>
>>> 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
>
> I would think that the rename is done in-place in the working copy. I
> considered the idea of copying to a temp space, but ruled it out for
> exactly this reason. Finding a name that doesn't exist shouldn't be that
> hard. Someone else already suggested a naming algorithm as an alternative
> to the recycle bin (oldname.revert.N where N is a unique number).
>
>>> 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.
>
> This is quite correct. Moving to the recycle bin isn't the fastest thing
> in the world. But it is safer that what we're doing now, and isn't THAT
> painful. I don't believe it would be worse than the time it takes to
> perform the revert itself in the vast majority of cases.
>
> Double revert time, never accidentally lose your changes. Reasonable trade
> off to me. But then I don't maintain the code. ;-)
>
>>> 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.
>
> Even if it's a day's work, or an hour's, it's frequently very hard to
> reproduce the same work again. I used to get really annoyed when I was
> writing an email for ten minutes, then accidentally hit back on the browser
> before sending. (I use gmail now, and those days are gone.) It was only
> ten minutes, but I was never able to reproduce the same message again.
> Multiply that by several files with subtle changes.
>
>> Oh, and you requested an option:
>> http://tortoisesvn.net/request_for_new_options
>
> LOL.
> *I* didn't request the option. I simply suggested that *you* could, if you
> so chose. I prefer this to be standard behavior for everyone. (And yes,
> I've used just about every option except perhaps the proxy server setting.)
>
> Someone else suggested that if you hold Shift while clicking OK, the
> recycle bin would be skipped. That's fine by me, too.
>
> -- Keith
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
> For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed Oct 18 22:57:35 2006