根据存储库定义边界

Question

我先把场景布置一下...

我们使用 Subversion，目前拥有相当大的主存储库。不过，我希望将其分解，并有可能在以后迁移到 Git。原因是 a) Git 无法执行子文件夹签出，因此有利于较小的存储库，b) 我们可以更多地使用分支（每个功能分支）。

我们有一个网络应用程序，还有一个网络自动化应用程序。

它们在代码方面并不直接相互依赖。但自动化应用程序在设计方面依赖于网络应用程序。如果在网络应用程序中进行更改，则可能会破坏自动化应用程序。

我想将它们分成单独的存储库，但提出了一个很好的观点。将它们放在同一个存储库下很方便，因此您知道在某个版本中它们可以一起工作。

用两个独立的存储库和两组修订号来解决这个问题显然是相当棘手的。另一个问题是我们有许多应用程序（不仅仅是相互依赖的自动化应用程序、API 等......）。

只是想看看人们的想法。如果您处理过这样的问题？你认为他们应该或不应该分开等等......您是否使用某种部署工具来跟踪每个存储库协同工作的各种修订版等等......

Answer 1

首先，创建svn存储库的克隆，然后可以使用 git filter-branch 拆分生成的git存储库。

再次使两个项目相关，使用子模块。这样，一个存储库可以与固定版本一起使用（对于库，对于Web应用程序来说很有用）

Answer 2

就工具而言，如果您使用 哈德逊, ，它会为您跟踪每个版本中使用的存储库集和修订号。如有必要，您可以从此标记。

如果您有一个以这种方式工作的工具，那么限制您跟踪的修订版本号的数量就不那么重要了。我是这样拆分的——1个号码可以手动追踪，>1个需要工具支持。但它们不需要是复杂的工具。

我更喜欢单个存储库，但这只是个人喜好。它基于明确的修订号，对于多个存储库，您需要存储库和编号。然后，回购边界取决于策略更改（例如，这一边界用于代码，这一边界用于公司文档，这一边界用于部署等）。

Git 不能以这种方式工作，因此您无法选择使用单个存储库。这并不是一件坏事，大多数系统（如 Hudson、Redmine）都会很乐意支持这一点。

Answer 3

拆分它们允许它们使用自己的版本号独立发布，但正如您所注意到的，跟踪依赖关系可能会非常棘手。我们从一个基于Ant的构建转向了maven，以帮助我们了解我们的依赖关系，尽管出现了一些问题，但它总体上是值得的。 （我们有多个应用程序以奇怪和奇妙的方式依赖于彼此的apis。）我们遵循的基本架构是使用 Apache Portable Runtime的版本编号，这是一个三位数的系统，版本使用标准的MAJOR.MINOR.PATCH约定。

就分割它们的过程而言，我建议先在Subversion中拆分它们;然后，当你转移到git时，你可以简单地将git svn指向存储库的相关部分进行转换。