我会先设置场景......
我们使用Subversion，目前拥有一个相当大的主存储库。我想打破它，有可能在以后转移到Git。原因是a）Git无法执行子文件夹检查，因此有利于较小的repo，b）我们可以使用更多的分支（每个功能的分支）。
我们有一个Web应用程序，还有一个Web自动化应用程序。
它们在代码方面并不直接相互依赖。但自动化应用程序在设计方面取决于Web应用程序。如果在Web应用程序中进行了更改，则可能会破坏自动化应用程序。
我想将它们分成单独的回购，但提出了一个很好的观点。将它们置于相同的回购下是很方便的，所以你知道在某个版本中它们一起工作。
用两个独立的回购计算出来，有两套修订版数字显然非常棘手。另一个问题是我们有许多应用程序（不仅仅是相互依赖的自动化应用程序，API等等）。
只是想看看别人的想法。如果你已经处理过这样的问题？你认为它们应该或不应该被拆分等等......你是否使用某种部署工具来跟踪每个repo一起工作的各种版本......
答案 0 :(得分：1)
首先，您创建了svn存储库的克隆，然后可以使用git filter-branch拆分生成的git存储库。
再次使两个项目相关，使用子模块。这样，一个存储库可以与固定版本一起使用（对于库，对于Web应用程序来说很有用）
答案 1 :(得分：1)
就工具而言，如果使用Hudson构建，它会跟踪每个构建中使用的存储库集和修订号。如有必要，您可以从中进行标记。
如果您有一个以这种方式工作的工具，那么限制您正在跟踪的修订号的数量并不是那么重要。我这样拆分 - 可以手动跟踪1个数字，＆gt; 1需要工具支持。但它们不需要是复杂的工具。
我更喜欢单个存储库，但这只是个人偏好。它基于一个明确的修订号，有多个仓库需要回购和数量。然后回购边界就是政策变化（例如，这个用于代码，这个用于公司文档，这个用于部署等）。
Git只是不起作用，所以你没有选择使用单个回购。这不是一件坏事，大多数系统（如Hudson，Redmine）都乐意支持这一点。
答案 2 :(得分：1)
拆分它们允许它们使用自己的版本号独立发布，但正如您所注意到的，跟踪依赖关系可能会非常棘手。我们从一个基于Ant的构建转向了maven，以帮助我们了解我们的依赖关系，尽管出现了一些问题，但它总体上是值得的。 （我们有多个应用程序以奇怪和奇妙的方式依赖于彼此的api。）我们遵循的基本模式是使用Apache Portable Runtime's version numbering，这是一个三位数系统，其中版本使用标准MAJOR.MINOR .PATCH惯例。
就分割它们的过程而言，我建议先在Subversion中拆分它们;然后，当你转移到git时，你可以简单地将git svn指向存储库的相关部分进行转换。