RFE: confirm before delete file (from context menu) that is not in repository

[zzo...@gmail.com]

Due to network lag (inside a virtual session), my attempted click on "Add" (on the context menu) slipped.

I didn't know what it landed on; the context menu of course vanishes immediately. But my file was no longer there, so I guessed that maybe it had deleted it, and I found my file in the recycle bin.

My RFE is for a confirm box before deleting files that are not in the repository.

[Stefan]

That's not an RFE but an RFD (Request for diminuition):

As you've noticed, the file you deleted was in the recycle bin. That's by design. Like the windows explorer (on recent Win-versions) does not ask for confirmation when deleting files, neither does TSVN.

At least not if the file can be moved to the recycle bin.

if the recycle bin is not available, then TSVN will ask you for confirmation.

[Ben Voigt]

I've accidentally hit "Delete" when I meant to click "Add" on at least two occasions separated a few months apart.  The recycle bin is not an obvious place to look (I had to find this thread) and a massive waste of time.

May I request an alternative enhancement that, unlike the original, doesn't add any extra steps when the use DID intend to delete?

1. When the Delete context menu option is chosen, no filesystem action is performed.  Instead the delete action goes on a local queue.  This local queue is separate from the svn queue of metadata modifications.

2. The file being deleted stays in the list of local modifications and unversioned files, but its status changes from "unversioned" to "delete unversioned".  So to the user, the queued filesystem action appears just like a staged version control action.

3. While the user is working in the Commit dialog, they can choose "Undo Delete" from the context menu, just like "Undo Add" works for cancelling staged actions.  Choosing the "Add" action also removes the queued delete action.

4. When the user submits the commit, the filesystem delete actually happens.

5. If the user cancels the commit dialog, the local delete queue can either be thrown away, or the user can be given a Yes/No confirmation dialog at this stage whether to perform the deletions.

The commit dialog already has "restore after commit", so a similar local queue already exists.

Staging deletion of a file which is versioned with local modifications should also delay actually losing those modifications (moving them to the recycle bin) until the commit is completed.

If this feature is deemed too much effort, can TortoiseSVN give the user a global preference to take "Delete" off the context menu for unversioned files?  TortoiseSVN is supposed to be exposing version control operations, and "delete an unversioned file" is not a version control operation!  Providing easy access to filesystem operations without the shell features like "Undo Delete" is a bug, not a feature.