将旧代码库从cvs传输到分布式存储库(例如git或mercurial)。初始存储库设计所需的建议[已关闭]

只是一个简短的评论,提醒您:

• 这些迁移通常提供了重新组织源的机会,而不是沿着模块(每个模块有一个存储库),而是沿着功能域拆分(同一给定功能域的多个模块放在同一存储库中)。

然后 submodules 将用作定义 configuration .

• 吉特很好,但是来自 Linus's admission himself 将所有内容放在一个存储库中是有问题的。

[…]cvs,也就是说,它实际上是面向“一个文件”的。 “一次”模式。

很好,你可以有一百万个文件,然后只检查 他们中的一些-你永远不会 看见 另一个的影响 99999个5个文件。

吉特 从根本上说,从来没有真正关注的少于整个回购。即使你 把事情限制一点(只检查一部分,或让历史过去) 稍微后退一点),Git最终仍然关心整个事情, 把知识带到身边。

所以如果你强迫它把所有的东西都看成一个的话,Git的规模真的很糟糕。 巨大的 储存库。我不认为那部分真的是固定的,尽管我们 可能会有所改善。

是的,那就是“大文件”问题。我真的不知道该怎么办 处理大文件。我知道,我们很讨厌他们。

前面提到的这两个点主张对大型系统(和大型遗留存储库)采用更面向组件的方法。

用 Git submodule ,您可以在项目中签出它们(即使这是两个步骤的过程)。但是,您拥有的工具比使子模块管理更容易( git.rake 例如)。

当我在考虑修复一个在多个项目之间共享的模块中的bug时,我只需修复并提交这个bug,所有人都只需进行更新。

这就是我在帖子里描述的 Vendor Branch 作为“系统方法”:每个人都在最新的(头)上工作,它对少数项目有效。
不过,对于大量模块而言,“模块”的概念仍然非常有用,但其管理与DVC不同:

• 对于密切相关的模块(又称“在同一功能域”,如“与PNL相关的所有模块——损益——或“风险分析”,在金融领域),您确实需要使用所有相关组件的最新(HEAD)。
  这可以通过使用 subtree strategy 不是为了发布(推送)其他子模块上的更正,而是为了跟踪其他团队完成的工作。
  Git允许这种额外的好处,即这种“跟踪”不必在您的存储库和一个“中央”存储库之间进行,也可以在您和另一个团队的本地存储库之间进行,允许在类似性质的项目之间进行非常快速的来回集成和测试。

• 但是,对于不直接在功能域中的模块,子模块是更好的选择,因为它们引用模块的修复版本(提交):
  当低级框架更改时,您不希望传播它 瞬间地 ,因为它会影响到所有其他团队,然后必须放弃他们正在做的事情,以使他们的代码适应新版本(您确实希望所有其他团队都知道这个新版本,以便他们不要忘记更新这个低级组件或“模块”)。
  这只允许您使用其他模块的官方稳定识别版本,而不是潜在的未稳定或未完全测试的头。

至于mercurial方面,建议还将大型的遗留cvs/svn存储库重构为较小的组件。公共代码应该放在自己的库中,然后应用程序代码将以类似于它如何依赖其他库的方式依赖这些库。

Mercurial拥有 forest extension 它允许您管理“源树”的“森林”。通过这种方法,您可以将几个较小的存储库组合成一个较大的存储库。对于cvs,则相反:签出大型存储库的较小部分。

我没有亲自使用这个森林扩展,它的页面上说,与Mercurial捆绑的版本相比,应该使用一个更新的版本。然而,它 是 被一个像太阳一样的大组织使用 OpenJDK project .

根据上的设计,目前还正在进行将子存储库报告直接添加到Mercurial的核心的工作。 nested repositories page 在反复无常的维基里。