CODEWITHSUNDEEP
svntortoisesvn
DARKHalf
DARKHalf

Reputation: 73

tortoise svn mass rename files merge

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

Upvotes: 1

Views: 2187

Answers (3)

Maakarov
Maakarov

Reputation: 23

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!)

Upvotes: 0

David W.
David W.

Reputation: 107040

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.

Upvotes: 0

Chris Thornton
Chris Thornton

Reputation: 15817

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.

Upvotes: 5

Related Questions