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

工作中的subversion存储库是在没有太多结构规划的情况下建立的。尽管通过使用subclipse:tags提供了一些标记元数据，但目前没有配置显式标记、主干或分支

当前存储库的格式为：

/科雷科迪亚

/CoreCodeB

/项目1

/项目2

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

/新/新科里亚

/新的/新的

/新建/项目3

/新建/项目4

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

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

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

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

用“预重组”标记存储库，按我的意愿重新组织存储库，用“后重组”标记存储库。

• 好：不会破坏历史建筑
• 坏：有效地将未来的工作与过去的工作断开，不容易发布x.x.1修补程序

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

• 良好：保持代码的历史连续性
• 错误：以前的版本已损坏，如果再次需要，肯定需要x.x.1补丁版本

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

• 好：代码的连续性得到了维护，项目应该构建
• 坏：编辑文件的实际内容比简单地更改有关其位置的元数据要脆弱得多

---

前两个选择很容易做到——但我希望其他开发者能给我一些现实世界中20-20年的后见，告诉我他们在类似情况下做了什么，什么是错的，什么是对的。

我不想触及历史。那时候很糟糕，如果你想再次回到那里，你必须付出代价

当然，您可能“知道”您会经常重温过去，那么使用#3并使用所有重要点的新.1版本完成整个回购计划可能是有意义的。

存储库布局（更改）更多的是关于您的开发组织，而不是任何技术性的。如果不知道代码的数量、重组后需要对代码进行的更改的数量以及处理代码的人员的数量，很难推荐任何具体的内容，但我首先要让所有受影响的人员都参与进来，并专门介绍1-距离回购大修还有2天-代码冻结，只允许修复代码可构建。最终，每个人都会更开心。尝试这样做可能会让你看到一个流氓开发人员仍在你的SVN服务器的某个黑暗角落里做他/她自己的分支

我也不太担心如何访问历史代码布局。您可以随时在/oldlayoutdonottouchthis下标记当前布局，而无需实际需要，并将其留在那里以修补旧版本。对于此类技巧，SVN是一个非常好的工具

---

另外，我从未使用过subclipse，但看起来subclipse标记与SVN标记这本书中的标记大不相同。它们似乎更像CVS标记。请确保您没有混淆。

有没有办法让构建属性文件反映相对路径而不是硬编码路径

假设您的任务涉及将主文件夹组织为标记、分支和主干，我认为子文件夹/文件（至少在一定程度上）将保留其相对位置

<>如果我是你，我会考虑修复我的属性文件，使之变得更通用，并且独立于绝对路径。

希望这有帮助…干杯