16

我工作的公司正在启动，他们在这个过程中更名了。所以我们仍然使用包名 com.oldname 因为我们害怕破坏文件更改历史，或者版本之间的祖先链接，或者我们可能破坏的任何东西（我不认为我使用了正确的术语，但你明白了这个概念）。

我们使用：Eclipse、TortoiseSVN、Subversion

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

  • 首先使用 TortoiseSVN 重命名目录，更新 .svn 目录。
  • 然后，手动将目录重命名为原始名称。
  • 最后使用 Eclipse 将包重命名（重构）回新名称，更新 java 文件。

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

我没有那台服务器的密钥，这就是为什么我不急于备份东西并尝试一两件事。我想提出一个不这样做的充分理由，或者一种可行的方法。

感谢您的帮助，

M·乔尼斯

包重命名测试

程序：

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

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

    类重命名测试0 {
    公共重命名测试0（）{
        显示消息（）；
        新的重命名测试1（）；
    }
    公共静态无效showMessage（）{
        System.out.println("重命名测试0！");
    }
    公共静态无效主要（字符串[]参数）{
        新的重命名测试0（）；
    }
}

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

    类重命名测试1 {
    公共重命名测试1（）{
        显示消息（）；
        重命名Test0.showMessage();
    }
    公共静态无效showMessage（）{
        System.out.println("重命名Test1!");
    }
}

  4. 测试 RenameTest0 运行良好。

  5. 犯罪。
  6. 更改两个类的消息。
  7. 犯罪。
  8. 再次，更改一个类的消息并提交（只是创建一些历史）。
  9. 应用上述程序（原始消息中的三个步骤）将包 renametest 重命名为 testrename。
  10. 犯罪。
  11. 测试运行。
  12. 再次修改消息并测试。
  13. 犯罪。
  14. 尝试回滚到第一次同时更改两条消息时的版本。
  15. 如果到目前为止一切正常，它看起来不错，不是吗？

测试结果：

  • 第 9 步的注意事项：必须以相反的顺序进行（Eclipse 重命名 THEN TortoiseSVN 重命名。），否则它会变得复杂，因为 TSVN 创建一个新文件夹/包并将旧文件夹/包标记为删除......所以你不能为 Eclipse 重命名，除非您同时将旧包放在其他地方以防止丢失 .svn 文件夹等。用这种方法走得更远看起来不是一个好主意。（我自己注意：不要忘记勾选递归包重命名复选框！）
  • 第 14 步的注意事项：工作！我们可以看到以前的版本；我们所要做的就是告诉不要在复制/移动时中断，这没关系。一旦恢复到重命名之前的版本，包名称虽然不会恢复到好名称，但可能再次重构它会做到这一点。
  • 尾注：我很惊讶必须以相反的顺序执行关键步骤。为了在第一次包重命名尝试中做到这一点，我不得不回滚一些 TSVN 和手动修改，对这个过程的确切结果的可重复性产生了一点怀疑。我将不得不进行第二次测试以确认它的有效性。总结：看起来不错，但需要进一步测试。
4

7 回答 7

8

也许它不适合您的确切需求，但 TortoiseSVN 有一个方便的重命名功能。你可以这样做：

  1. 使用 IDE 的重构功能重命名内容。
  2. 从 TortoiseSVN 启动“检查修改”对话框。
  3. 对于每个重命名的项目，您将看到两个条目：一个缺失的“source.java”项目和一个未版本化的“target.java”项目。突出显示两者并从上下文菜单中选择“修复移动”。

修复移动/重命名

于 2010-03-23T16:15:00.697 回答
3

您是否考虑过使用Subclipse 插件？根据如何使用 Eclipse 重构工具并通过 Subclipse 与 SVN 保持同步，它可能会解决您的问题？

于 2010-03-23T16:04:27.437 回答
2

如果您使用 eclipse 中包含的重构方法，您确定保留历史记录不起作用吗？

使用 NetNeans，我会定期更改包名称，并且底层的“svn 插件”会默默地将内容（保存历史记录）移动到新目录中（之后将进行正常的重构）。

所以：如果历史记录与颠覆插件一起保存，您是否在 Eclipse 中尝试过？（例如，在新的签出副本中以避免失败）

至少您可以使用 NetBeans 来完成这项一次性任务......

于 2010-03-21T09:47:56.833 回答
0

是的，它会起作用。您可以安装 svn 的命令行版本并编写一个批处理文件来执行 svn 的工作。自动化 eclipse 的东西会多一点工作，而且可能不值得，除非您已经熟悉 eclipse API。

在你做所有事情之前用一个包测试它只是为了确保你做的所有步骤都是正确的。

于 2010-03-21T05:02:06.393 回答
0

您可以做到这一点，而且并不难——获得干净的 SVN 历史记录的最佳选择是分两步完成（可以成为一次提交）——尽管为了获得良好的结果，我建议使用 CLI 客户端。

  1. 使用 svn mv 移动文件夹/包
  2. 进入 Eclipse，或使用 CLI 中的 grep 修复文件中的包以匹配新名称

然后你可以作为一个变更集提交，并且文件级别的历史应该匹配。

如果您使用的是 Maven 或打包工具，建议您在执行此类操作之前先运行一个版本 - 此外，在此之前立即剪切一个标签以防您需要返回旧结构

于 2010-03-22T16:51:57.590 回答
0

我发现 subclipse 插件在提交已移动到新包（即尚未受源代码控制）的类时给出错误消息“已在版本控制下”，并且该包的父级也是新的。

发生这种情况时，我可以使用 TortoiseSVN 提交更改。之后我只需要在 Eclipse 中刷新项目。

在将一个类移动到其父级已在源代码控制下的新包后，subclipse 可以毫无问题地提交此更改。

于 2013-01-02T10:00:49.807 回答
0

您可以这样做，而不是重命名包：

  1. 在您的项目中创建新的包结构。完成后，您的项目应如下所示：

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

  2. 在版本控制下添加新文件夹，以便 svn 可以跟踪它们

  3. 将您的 java 类从旧包移动到新包。Eclipse 应该相应地更新所有类的导入和包声明。最重要的是，因为新旧包都在 vcs 下，所以这一步应该保留类的历史。
  4. 完成后删除旧文件夹
  5. 犯罪！
于 2015-03-07T10:25:57.860 回答