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

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 TortoiseSVN 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.