重组subversion存储库的长期影响是什么？

Question

工作中的颠覆存储库在没有太多规划其结构的情况下建立.目前没有配置显式标签,主干或分支,尽管通过使用subclipse:标签存在一些标记元数据

目前,存储库的格式如下:

/ CoreCodeA

/ CoreCodeB

/ PROJECT1

/ Project2的

最近,一位新开发人员开始使用我的内部应用程序的"第2版",并将其置于不同的文件夹中:

/新/ NewCoreA

/新/ NewCoreB

/新/项目3

/新/ Project4

这些项目都依赖于核心代码的各个部分,以及类似的项目(例如,几个项目可能依赖于相同的主题).这些依赖项在一些基于文本的项目属性文件的内容中引用.

我一直在使用svndumpfilter命令,通过sed管道输出并将其重组为两个单独的存储库("旧"和"新").很容易做到,我现在有两个不同的存储库,其中设置了主干,标签和分支(subclipse标记信息可以在以后重新分析).

我担心的是,通过在每次提交时摆弄subversion结构,我打破以前工作的构建,特别是考虑到对其他项目的依赖.另一方面,我需要尽快在此代码库中使用标记和分支.但是,如果我在几个月后改变主意,我也不想强迫开发人员重新检查他们的项目.

我猜我对每个存储库的选择是:

1. 使用"预重组"标记标记存储库,按照我想要的方式重新组织存储库,标记为"重组后".
   • 好:不会破坏历史建筑
   • 错误:有效地将未来的工作与过去的工作断开,没有简单的能力来制作xx1补丁版本
2. 重构整个存储库,打破以前的构建
   • 好:保持代码的历史连续性
   • 错误:以前的版本被破坏,如果再次需要,肯定需要xx1补丁版本
3. 重构整个存储库并在每个阶段编辑项目属性文件
   • 好:维护代码的连续性并构建项目
   • 错误:编辑文件的实际内容比简单地更改有关其位置的元数据要脆弱得多

前两个选项很容易做到 - 但是我想从其他开发者那里得到一些20-20事后的真实世界,了解他们在类似情况下做了什么,以及出了什么问题或者说错了.

Answer 1

存储库布局（更改）更多的是关于您的开发组织，而不是任何技术。在不知道代码量、重组后代码中需要更改的数量以及处理代码的人员数量的情况下，很难推荐任何具体的内容，但我会首先让所有受影响的人参与进来，然后专门用 1-2 天的时间进行存储库大修 - 代码冻结，只允许进行使代码可构建的修复。最终，每个人​​都会更加幸福。试图秘密进行此操作可能会让您遇到一个流氓开发人员，他们仍在您的 SVN 服务器的某个黑暗角落里做他/她自己的分支。

而且我不会太担心访问历史代码布局。您始终可以在 /oldlayoutdonottouchthiswithoutrealneed 等内容下标记当前布局，并将其保留在那里以修补旧版本。对于这样的技巧，SVN 是一个非常好的工具。

PS 我从未使用过 subclipse，但看起来 subclipse 标签与书本上的 SVN 标签有很大不同。他们似乎更喜欢 CVS 标签。确保您不会在那里感到困惑。