我在大约10个目录中有大约500个文件的源代码。我需要重构目录结构 - 这包括更改目录层次结构或重命名某些目录。
我正在使用svn版本控制。重构有两种方法：一种保留svn历史（使用svn move命令），另一种不保留。我认为使用eclipse CDT和SVN插件重构保存svn历史要容易得多（visual studio根本不适合目录重构）。
但是由于代码未发布，我们现在可以选择不保存历史记录。
仍然存在更改头文件的include指令的任务，无论它们包含在哪里。我正在考虑使用python编写一个小脚本 - 接收从当前文件名到新文件名的映射，并在需要的地方进行重命名（使用像sed这样的东西）。有没有人做过这种目录重构？你知道很好的相关工具吗？
答案 0 :(得分：3)
如果您不得不重写#include来执行此操作，那么您做错了。更改所有#includes以使用非常简单的目录结构，在两个级别深层，并且仅使用第二级来组织架构或操作系统依赖项（如sys/types.h）。
然后将您的make文件更改为使用-I包含路径。
瞧。你永远不必为此再次破解代码，如果出现问题，编译会立即爆炸。
就历史部分而言，我个人觉得在做这类事情时更容易干净利落;存档旧的，创建一个新的存储库v2，从那里开始。反驳是指存在大量变更历史或许多针对现有代码的未解决的问题。
哦，而且你确实有很好的测试，而且你不会在发布的时候做到这一点，对吗？
答案 1 :(得分：2)
我会保留历史，即使需要少量的额外时间。能够通过提交日志读取并理解为什么函数X以奇怪的方式编写，或者这确实是一个错误的错误是有很多价值的，因为它是由Oliver编写的，他总是出错。
可以为以下用户提供反对保留历史记录的论据：
去年我在代码库上做了一些像这样的目录重构。如果您的代码在开始时结构合理，您可以使用以您选择的语言编写的脚本（我使用Perl）完成大约75-90％的工作。在我的例子中，我们从一个大目录中的文件集转移到一系列嵌套目录，具体取决于命名空间。因此，声明类protocols :: serialization :: SerializerBase的文件位于src / protocols / serialization / SerializerBase中。从旧名称到新名称的映射是微不足道的，因此在树中的每个源文件中对#includes进行查找和替换是微不足道的，尽管这是一个很大的变化。我们必须手工修复一些奇怪的边缘情况，但这似乎要比手动完成所有操作或编写我们自己的C ++解析器要好得多。
答案 2 :(得分：2)
黑客攻击shell脚本来执行 svn 移动是微不足道的。在 tcsh 中， foreach F（$ FILES）...结束来调整一组文件。 Perl＆amp; Python提供了更好的实用性。
真的值得挽救历史。特别是当试图追踪一些异国情调的虫子时。那些没有从历史中吸取教训的人注定要重复它，或者一些这样的垃圾......
至于更改所有文件......前几天有一个类似的问题：