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?

Answer 3

Are you sure keeping history is NOT working if you are using the refactoring method included in eclipse?

With NetNeans I regularly change package names and the underlying 'svn plugin' will silently move the content (which saves history) into the new directory (after that the normal refactoring will happen).

so: Have you tried it from within eclipse if the history is kept with the subversion plugin? (e.g. in a fresh check-out copy to avoid failure)

At least you could use NetBeans to do this one-time task ...

Answer 4

Yes, it will work. You could install the command line version of svn and write a batch file that will do the svn stuff. Automating the eclipse stuff would be a bit more work, and probably not worth it unless you're already familiar with the eclipse API.

Test it with one package before you do everything just to make sure you're doing all the steps right.

Answer 5

You can do this, and it's not that hard - your best bet to get a clean SVN history is to do it in 2 steps (can become one commit) - though for good results I recommend using the CLI client.

1. Use svn mv to move the folders/packages
2. Go into Eclipse, or use grep from the CLI to fix the packages in the files to match the new name

Then you can commit as a change-set, and the history at the file level should match.

If you're using Maven or a packaging tool, recommend you run a release before doing something like this - also it's worth cutting a tag immediately before this in case you need to go back to the old structure

Answer 6

I discovered that the subclipse plugin gives the error message " is already under version control" when committing a class that has been moved to a new package (i.e. not under source control yet) and the parent of this package is also new.

When this happens, I can commit the changes using TortoiseSVN. After that I only need to refresh the project in Eclipse.

After moving a class to a new package whose parent is already under source control, subclipse can commit this change without problems.

Answer 7

Instead of renaming the packages you could do this:

1. create the new package structure in your project. Once done your project should look something like this:

          com -
              |- myOLDcompname -
              |                |- feature1 -
              |                            |- classA.java
              |                            |- classB.java
              |- myNEWcompname -
                               |- feature1
   

2. add the new folders under version control so svn can track them

3. move your java classes from old packages to new ones. Eclipse should update all the classes imports and package declarations accordingly. Most importantly because old and new packages are under vcs this step should keep the history of the classes.
4. when done delete the old folders
5. commit!