0

I have a folder in where a co worker had to rename all files in it. The folder has about 12000 files which were renamed with a renaming tool. Now I have the problem that Tortoise SVN does not recognize the files as the names are different now. This leads to my question: can I tell subversion that the files were renamed so that it looks in the folders and looks for the matching files? Contents did not change, but only the names.

I know there is a way to tell tortoise that a file was renamed if you select both, the missing entry and the new file and choose "repair move". But this is only possible for two files. I have 12000 files and no one will rename them by hand. The file names changed only partly. e.g.: data.00001.house.txt -> data.house.txt

Any help would be appreciated. Greetings, Florian

Álvaro González
  • 142,137
  • 41
  • 261
  • 360
DARKHalf
  • 63
  • 10
  • This is almost a duplicate of "SVN “repair move” from the command-line" at https://stackoverflow.com/questions/4763832/svn-repair-move-from-the-command-line – james Sep 22 '14 at 16:00
  • Not really at all. I do not have the option to do a svn mv . Because I have only the changed file names. Additionally the mentioned solution is for one file but I have 12000. – DARKHalf Sep 22 '14 at 16:38
  • Would it be possible to check out an earlier revision of the repository (prior to the rename) and compare the two working copies in some way? EDIT: Also this may be relevant: http://stackoverflow.com/questions/2195415/how-to-tell-tortoisesvn-that-a-renamed-file-was-renamed-not-deleted-and-re-adde – orbrey Sep 22 '14 at 16:55
  • @DARKHalf, my point was that they had the same problem and seemed to discover the method(s) to recover. Basically, you're going to have to emulate what TortoiseSVN "repair move" does and then do that 12000 times. For instance, can you check out another copy and then, using the same tool used to rename, cause a rename script to be generated instead of the renames executed? – james Sep 22 '14 at 18:48
  • @james: yes, that may be the only way to cover that. The problem is that I was looking for an existing tool. It seems that I have to develop / script one by myself to get that thing solved. – DARKHalf Sep 23 '14 at 08:13

3 Answers3

5

I think you have to re-visit you co-worker's rename tool. Hopefully it's a .bat file or something that can be modified.
Change it so that it properly uses the SVN MOVE command. 

i.e. instead of:
mv <oldname> <newname>
use:
SVN MOVE <oldname> <newname>

You will notice that this isn't really a Tortoise solution, but a generic Subversion solution, using the Subversion command-line "SVN MOVE" command. see: http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.move.html

Test that on a small scale to ensure that it works. Then delete all of his bad files, revert his changes, re-run the new utility, check it in, and you're done.

Chris Thornton
  • 15,620
  • 5
  • 37
  • 62
0

How were the files renamed? Here's a sort of command line description of the evil way:

copy %FILE% %DIR%
svn delete %FILE%
svn add %DIR%\%FILE%
svn commit -m"Moved %FILE% to %DIR."

In this method, the file is copies to a new location, and the old file is deleted and the new one added. The problem with this is that to Subversion the old deleted file has no relationship to the newly deleted one. It is similar to this:

svn delete --keep-local foo
svn add foo
svn commit -m"Deleted and added foo"

I deleted a file called foo (and kept the local copy), then added it back in. To Subversion, even though both foo files are in the same directory, and even have the same contents, they're two different files that don't share a common history.

What you want to make sure your rename tool is doing is:

svn move %FILE% %DIR%
svn commit -m"Moved %FILE% to %DIR"

How did your rename tool work? That's the $64,000 question. The best thing to do is take a log of one of the renamed files (with verbose mode, and make sure stop-on-copy is not set) and see if the history follows back to the old location and names.

If not, you will probably have to do the renaming over. This means undoing the initial rename, committing that change, and then redoing that renaming the correct way.

Use the command line tool, and don't depend upon third party tools.

Let's say that the renaming took place in revision 12345:

C> svn merge -c -12345 .

This will undo Change 12345

Now, you have to rename each file. I'm not a batch expert, but for each file, use svn move to do the rename.

David W.
  • 105,218
  • 39
  • 216
  • 337
0

This post is pretty old now, but someone might still be looking for answers around here, like I did ;)

So, if you're using TortoiseSvn this can be solved by changing this option to 'false' (as shown) in the settings menu.

screenshot

Then, rename your files again and the client won't change them back (hopefully!)

Maakarov
  • 13
  • 3