How to rename Java packages without breaking Subversion history?

Question

The company I'm working for is starting up and they changed their name in the process. So we still use the package name com.oldname because we are afraid of breaking the file change history, or the ancestry links between versions, or whatever we could break (I don't think I use the right terms, but you get the concept).

We use: Eclipse, TortoiseSVN, Subversion

I found somewhere that I should do it in many steps to prevent incoherence between content of .svn folders and package names in java files:

• First use TortoiseSVN to rename the directory, updating the .svn directories.
• Then, manually rename the directory back to the original name.
• To finally use Eclipse to rename the packages (refactor) back to the new name, updating the java files.

That seems good to me, but I need to know if the ancestry and history and everything else will still be coherent and working well.

I don't have the keys to that server, that's why I don't hastily backup things and try one or two things. I would like to come up with a good reason not to do it, or a way of doing it which works.

Thank you for your help,

M. Joanis

---

Package rename test

Procedure:

1. Create a new package com.oldname.test.renametest.subpackage.

2. Add a new class under renametest called RenameTest0.java and containing:

   class RenameTest0 {
       public RenameTest0() {
           showMessage();
           new RenameTest1();
       }
       public static void showMessage() {
           System.out.println("RenameTest0!");
       }
       public static void main(String[] args) {
           new RenameTest0();
       }
   }

3. Add a new class under renametest.subpackage containing:

   class RenameTest1 {
       public RenameTest1() {
           showMessage();
           RenameTest0.showMessage();
       }
       public static void showMessage() {
           System.out.println("RenameTest1!");
       }
   }

4. Test that RenameTest0 runs fine.

5. Commit.
6. Change the messages of both of the classes.
7. Commit.
8. Again, change the message of one class and commit (just creating some history).
9. Apply procedure proposed above (the three steps in the original message) for renaming package renametest to testrename.
10. Commit.
11. Test run.
12. Modify the messages again and test.
13. Commit.
14. Try to roll back to the version when both messages have been changed simultaneously the first time.
15. If everything worked fine to this point, it looks good, no?

Result of test:

• Note on step 9: Had to do it in reverse order (Eclipse rename THEN TortoiseSVN rename.), else it was getting complicated, as TSVN create a new folder/package and marks the old one for deletion... So you can't rename for Eclipse unless you put the old package somewhere else in the meantime to prevent losing .svn folders, etc. etc. Didn't look like a good idea to go further with this method. (Note to myself: don't forget to tick the checkbox for recursive package renaming!)
• Note on step 14: Worked! We can see previous versions; all we have to do is tell not to break on copy/move and it's ok. Once reverted to a version before the rename, the package names are not back to the good name though, probably that refactoring it again would do it.
• End note: I was surprised to have to do the critical steps in reverse order. To do that right in the middle of this first package rename try, I had to roll back some TSVN and manual modifications, casting a little doubt on the repeatable nature of the exact results of this procedure. I will have to do a second test to confirm it's validity. To sum up: it looks good, but needs further testing.

Answer 1

Perhaps it's not practical for your exact needs but TortoiseSVN has a handy feature regarding renames. You could do this:

1. Use your IDE's refactoring feature to rename stuff.
2. Launch the "Check for modifications" dialogue from TortoiseSVN.
3. For each renamed item, you'll see two entries: a missing "source.java" item and an unversioned "target.java" item. Highlight both and choose "Repair move" from the context menu.

Repair moves/renames

Answer 2

Have you considered using the Subclipse plugin? It may solve your problems, according to How do I use Eclipse Refactoring Tools and stay in sync with SVN through Subclipse?