Unlike CVS, Subversion allows renaming and moving of files and folders. So there are menu entries for delete and rename in the TortoiseSVN submenu.
Use → to remove files or folders from subversion.
When you → a file, it is removed from your working copy immediately as well as being marked for deletion in the repository on next commit. The file's parent folder shows a “deleted” icon overlay. Up until you commit the change, you can get the file back using → on the parent folder.
When you → a folder, it remains in your working copy, but the overlay changes to indicate that it is marked for deletion. Up until you commit the change, you can get the folder back using → on the folder itself. This difference in behaviour between files and folders is a part of Subversion, not TortoiseSVN.
If you want to delete an item from the repository, but keep it locally as an unversioned file/folder, use → . You have to hold the Shift key while right clicking on the item in the explorer list pane (right pane) in order to see this in the extended context menu.
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 → .
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.
If you want to do a simple in-place rename of a file or folder, use → Enter the new name for the item and you're done.
If you want to move files around inside your working copy, perhaps to a different sub-folder, use the right-mouse drag-and-drop handler:
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 →
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 when your co-workers update, the old file will not be removed. 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.
You can also use the repository browser to move items around. Read the section called “The Repository Browser” to find out more.
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.
Making case-only changes to a filename is tricky with Subversion on Windows, because for a short time during a rename, both filenames have to exist. As Windows has a case-insensitive file system, this does not work using the usual Rename command.
Fortunately there are (at least) two possible methods to rename a file without losing its log history. It is important to rename it within subversion. Just renaming in the explorer will corrupt your working copy!
Solution A) (recommended)
Commit the changes in your working copy.
Rename the file from UPPERcase to upperCASE directly in the repository using the repository browser.
Update your working copy.
Solution B)
Rename from UPPERcase to UPPERcase_ with the rename command in the TortoiseSVN submenu.
Commit the changes.
Rename from UPPERcase_ to upperCASE.
Commit the changes.
If the repository already contains two files with the same name
but differing only in case (e.g. TEST.TXT
and test.txt), you
will not be able to update or checkout the parent directory
on a Windows client. Whilst Subversion supports case-sensitive
filenames, Windows does not.
This sometimes happens when two people commit, from separate working copies, files which happen to have the same name, but with a case difference. It can also happen when files are committed from a system with a case-sensitive file system, like Linux.
In that case, you have to decide which one of them you want to keep and delete (or rename) the other one from the repository.
Preventing two files with the same name
There is a server hook script available at: http://svn.collab.net/repos/svn/trunk/contrib/hook-scripts/ that will prevent checkins which result in case conflicts.
Sometimes your friendly IDE will rename files for you as part of a refactoring exercise, and of course it doesn't tell Subversion. If you try to commit your changes, Subversion will see the old filename as missing and the new one as an unversioned file. You could just check the new filename to get it added in, but you would then lose the history tracing, as Subversion does not know the files are related.
A better way is to notify Subversion that this change is actually a rename, and you can do this within the Commit and Check for Modifications dialogs. Simply select both the old name (missing) and the new name (unversioned) and use → to pair the two files as a rename.
Usually you set your ignore list such that all generated files are ignored in Subversion. But what if you want to clear all those ignored items to produce a clean build? Usually you would set that in your makefile, but if you are debugging the makefile, or changing the build system it is useful to have a way of clearing the decks.
TortoiseSVN provides just such an option using → . You have to hold the Shift while right clicking on a folder in the explorer list pane (right pane) in order to see this in the extended context menu. This will produce a dialog which lists all unversioned files anywhere in your working copy. You can then select or deselect items to be removed.
When such items are deleted, the recycle bin is used, so if you make a mistake here and delete a file that should have been versioned, you can still recover it.