Unlike CVS, Subversion allows renaming and moving of files and folders. So there are menu entries for delete and rename in the TortoiseSVN submenu.
If you delete a file/directory using TSVN, the file is removed from your working copy and marked for deletion. The file's parent folder shows a "deleted" icon overlay. You can always get the file back, if you call → on the parent folder.
If you want to move files inside a working copy, use the drag-and-drop handler again:
select the files or directories you want to move
right-drag them to the new location inside the working copy
release the right mouse button
in the popup menu select →
Do Not SVN Move Externals
You should not use the TortoiseSVN
Move or Rename
commands on a folder which has been created using
svn:externals.
This action would cause the external item to be deleted from
its parent repository, probably upsetting many other people.
If you need to move an externals folder you should use an
ordinary shell move, then adjust the
svn:externals properties of the source
and destination parent folders.
If a file is deleted via the explorer instead of using the TortoiseSVN context menu, the commit dialog shows those files and lets you remove them from version control too before the commit. However, if you update your working copy, Subversion will spot the missing file and replace it with the latest version from the repository. If you need to delete a version-controlled file, always use → so that Subversion doesn't have to guess what you really want to do.
If a folder is deleted via the explorer instead of using the TortoiseSVN context menu, your working copy will be broken and you will be unable to commit. If you update your working copy, Subversion will replace the missing folder with the latest version from the repository and you can then delete it the correct way using → .
Commit the parent folder
Since renames and moves are done as a delete followed by an add you must commit the parent folder of the renamed/moved file so that the deleted part of the rename/move will show up in the commit dialog. If you don't commit the removed part of the rename/move, it will stay behind in the repository and an update of your coworkers won't remove the old file. i.e. they will have both the old and the new copies.
You must commit a folder rename before changing any of the files inside the folder, otherwise your working copy can get really messed up.
Getting a deleted file or folder back
If you have deleted a file or a folder and already committed that delete operation to the repository, then a normal → can't bring it back anymore. But the file or folder is not lost at all. If you know the revision the file or folder got deleted (if you don't, use the log dialog to find out) open the repository browser and switch to that revision. Then select the file or folder you deleted, right-click and select → as the target for that copy operation select the path to your working copy.