如何重命名Java包而不破坏Subversion历史记录？ [英] How to rename Java packages without breaking Subversion history?

问题描述

我正在为之工作的公司正在启动，他们在此过程中更改了名称。因此我们仍然使用包名com.oldname，因为我们害怕打破文件更改历史记录，或者版本之间的祖先链接，或者我们可以破坏的任何东西（我不认为我使用正确的术语，但是你得到了概念我们使用：Eclipse，TortoiseSVN，Subversion

我发现某处，我应该在很多步骤中执行此操作，以防止.svn文件夹的内容之间的不一致java文件中的包名：

• 首先使用TortoiseSVN重命名目录，更新.svn目录。


• 然后，手动将目录重命名为原始名称。


• 最后使用Eclipse将包重命名（refactor）重命名为新名称，更新java文件。

这对我来说似乎很好，但我需要知道祖先和历史以及其他一切是否仍然是连贯的运作良好。

我没有该服务器的密钥，这就是为什么我不急着备份东西并尝试一两件事。我想提出一个很好的理由不这样做，或者做一些有效的方法。

感谢您的帮助，

M. Joanis

---

包重命名测试

程序：

1. 创建一个新包com.oldname.test.renametest.subpackage。



2. 在renametest下添加一个名为RenameTest0.java的新类，其中包含：

    class RenameTest0 {
    public RenameTest0（）{
    showMessage（）; 
    new RenameTest1（）; 
   } 
    public static void showMessage（）{
    System.out.println（RenameTest0！）; 
   } 
    public static void main（String [] args）{
    new RenameTest0（）; 
   } 
   } 




3. 在renametest.subpackage下添加一个新类，其中包含：

    class RenameTest1 {
    public RenameTest1（）{
    showMessage（）; 
    RenameTest0.showMessage（）; 
   } 
    public static void showMessage（）{
    System.out.println（RenameTest1！）; 
   } 
   } 




4. 测试RenameTest0运行正常。



5. Commit。


6. 更改两个类的消息。


7. 提交。


8. 再次，更改一个类的消息并提交（只创建一些历史记录）。


9. 应用上面提出的程序（原始消息中的三个步骤），将包重命名重命名为testrename。


10. 提交。


11. 测试运行。


12. 再次修改消息并进行测试。


13. 提交。


14. 尝试在第一次同时更改两条消息时回滚到版本。


15. 如果一切正常点，它看起来不错，不是吗？

测试结果：

• 关于步骤9的注意事项：必须以逆序（Eclipse重命名THEN TortoiseSVN重命名。）进行，否则它变得复杂，因为TSVN创建了一个新的文件夹/包标记旧的删除...所以哟你不能为Eclipse重命名，除非你同时把旧包放在其他地方以防止丢失.svn文件夹等等。使用这种方法看起来不是一个好主意。 （请注意：不要忘记勾选递归包重命名的复选框！）


• 关于步骤14的注意事项：工作了！我们可以看到以前的版本;我们所要做的就是告诉不要打破复制/移动，这没关系。一旦恢复到重命名之前的版本，包名称不会回到好名称，可能会重新进行重构就可以了。


• 结尾注释：我很惊讶必须以相反的顺序执行关键步骤。为了在第一个包重命名尝试中做到这一点，我不得不回滚一些TSVN和手动修改，对这个过程的确切结果的可重复性质产生一些疑问。我将不得不做第二次测试以证实它的有效性。 总结：它看起来不错，但需要进一步测试。

解决方案

也许这对你的确切需求并不实际，但TortoiseSVN有一个关于重命名的便利功能。你可以这样做：

1. 使用IDE的重构功能重命名。


2. 启动检查修改来自TortoiseSVN的对话。


3. 对于每个重命名的项目，您将看到两个条目：缺少source.java项和未版本化的target.java项。突出显示两者并从上下文菜单中选择修复移动。

修复移动/重命名

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.

解决方案

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

这篇关于如何重命名Java包而不破坏Subversion历史记录？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！