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

Question

工作中的 subversion 存储库是在没有对其结构进行太多规划的情况下建立的。目前没有明确的标签、主干或分支配置，尽管通过使用 subclipse:tags 存在一些标签元数据

目前存储库的格式为:

/CoreCodeA

/CoreCodeB

/Project1

/Project2

最近，一位新开发人员开始使用我们内部应用程序的“版本 2”，他将其放置在不同的文件夹中:

/new/NewCoreA

/new/NewCoreB

/new/Project3

/new/Project4

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

我一直在使用 svndumpfilter 命令，通过 sed 管道输出并将其重新组织到两个单独的存储库(“旧”和"new")。很容易做到，我现在有两个不同的存储库，设置了主干、标签和分支(子剪辑标记信息可以在以后重新解析)。

我担心的是，通过在每次提交时摆弄 subversion 结构，我正在破坏以前有效的构建，特别是考虑到对其他项目的依赖。另一方面，我需要尽早在此代码库中添加标签和分支。但是，如果我在几个月后改变主意，我也不想强制开发人员重新检查他们的项目。

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

用“重组前”标签标记存储库，按照我想要的方式重组存储库，用“重组后”标记。

好:不会破坏历史建筑

不好:有效地将 future 的工作与过去的工作断开，不容易制作 x.x.1 补丁版本

重构整个存储库，打破以前的构建

好:保持代码的历史连续性

坏:以前的版本被破坏了，如果再次需要，肯定需要 x.x.1 补丁发布

重构整个存储库并在每个阶段编辑项目属性文件

好:保持代码的连续性，项目应该构建

坏处:编辑文件的实际内容比简单地更改有关其位置的元数据要脆弱得多

前两个选择很容易做 - 但我想从其他开发人员那里得到一些真实世界 20-20 的事后见识，关于他们在类似情况下做了什么，出了什么问题或正确的地方。

Answer 1

存储库布局(更改)更多的是关于您的开发组织而不是任何技术。在不知道代码量、重组后需要更改的代码数量以及处理代码的人数的情况下，很难推荐任何具体的东西，但我会首先让所有受影响的人都参与进来，并且将 1-2 天用于 repo 大修 - 代码卡住，只允许修复以使代码可构建。最后，每个人都会更快乐。尝试做这个卧底可能会让你发现一个流氓开发人员仍在你的 SVN 服务器的某个黑暗角落里做他/她自己的分支。

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

附言我从未使用过 subclipse，但看起来 subclipse 标签与 by-the-book SVN 标签完全不同。他们似乎更喜欢 CVS 标签。确保你没有混淆。