Losing SVN history on files during refactoring

Question

During some refactoring, I'm moving files around. Obviously SVN sees this as deleting the file and creating a new one since the IDE doesn't trigger an SVN rename/move operation. However I thought the SVN server would be smart enough to detect it, but this is not proving to be the case... not all the time anyway. I'm using Tortoise SVN and I am unchecking the "stop on copy/rename" button.

Is this expected? Is there a way round it? Should I move files using Tortoise SVN shell commands rather than letting the IDE do a regular file move?

Also, is it possible to manually force SVN to link two files as the same entity if it doesn't know? Like tell it "/com/john/test.tct is the same as /com/john/test/file.txt"?

Answer 1

You could install the (free) visual studio add-in AnkhSVN. This will track your file-renames and you won't lose the history in subversion.

File renames are tracked by the subversion client. If you rename files without using the subversion client (using windows explorer or visual studio solution explorer instead of TortoiseSVN or AnkhSVN), then subversion won't recognise the rename operation (only a delete and an add operation).

BTW: using AnkhSVN gives you some other advantages, such as the displaying the subversion status of files directly in the solution explorer.

Alternatively there's also VisualSVN, which is comparable to AnkhSVN, but is commercial.

Answer 2

The SVN way to do this is actually to have SVN rename the file (svn move or using TortoiseSVN's "Rename"). However, if you absolutely must have some external tool to perform the rename operation, you can use Tortoise to repair the move operation. The following will tell SVN that the new file is actually the renamed old one:

1. Open the "Check for Modifications" Window.
2. Mark both the old file name (listed as missing) and the new one (listed as unversioned)
3. Right click this selection and chose "Repair Move".

Note: I'm typing this from memory. It might not be fully correct. And there might be other ways to do this (like marking the files in the explorer).

If you already lost the history on a file where you miss it badly, you could resurrect the old file (you do this by svn copying an old revision's version into its old place), merge the new file's history into it, then delete the new file, and svn move the old file to the new file's name.