将遗留代码库从cvs传输到分布式存储库（例如git或mercurial）。初始存储库设计所需的建议 导言和背景

我们正在改变源代码管理系统，目前正在评估git和mercurial。总的代码库大约有600万行代码，所以不是很大，也不是很小

首先，让我简单介绍一下当前存储库设计的外观

我们有一个用于完整代码库的基本文件夹，在该级别下，有在多个不同上下文中使用的各种模块。例如，“dllproject1”和“dllproject2”可以看作是完全独立的项目

我们正在开发的软件被称为配置器，可以根据不同的客户需求进行无休止的定制。我们大概总共有50种不同的版本。然而，他们有一个共同点。它们都共享两个必选模块（必选模块1..）。这些文件夹基本上包含内核/核心代码和公共语言资源等。所有定制可以是其他模块（模块1..）之间的任意组合

因为我们目前使用的是cvs，所以我们在CVSROOT/modules文件中添加了别名。它们可能看起来像：

core –a mandatory_module1 mandatory_module2 mandatory_module3
project_x –a module1 module3 module5 core

因此，如果有人决定参与project_x，他/她可以快速签出以下所需的模块：

base>cvs co project_x

问题 直观地说，将基本文件夹作为单个存储库是不对的。作为程序员，您应该能够检查出当前项目所需的确切代码子集。你对此有何看法

另一方面，将这些模块放在单独的存储库中感觉更合适。但是这使得程序员很难检查出他们需要的模块。您应该可以通过一个命令来完成这项工作。所以我的问题是：在git/mercurial中定义别名有类似的方法吗

欢迎提出任何其他问题、建议和建议

---

注：我搜索过类似的问题，但没有发现其中任何一个问题100%适用于我的情况。

只是一个简短的评论，提醒您：

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

然后将它们用作定义

• Git是可以的，但是从，到将所有内容放在一个存储库中可能会有问题

[…]CVS，即它实际上最终几乎面向“一个文件” “一次一个”的模式

这很好，因为你可以有一百万个文件，然后只检查 其中的一些——你甚至看不到另一个的影响 99995个文件

吉特 从根本上说，从来没有真正看不到整个回购协议。即使你 把事情限制一点（只检查一部分，或让历史记录消失） 退后一点），git最终仍然关心整件事， 把知识带到身边

所以，如果你强迫git把所有东西都看作一个整体，它的伸缩性就非常差 巨大的存储库。我不认为那部分真的是可以修复的，尽管我们 可能会有所改进

是的，还有“大文件”问题。我真的不知道该怎么办 不要处理大文件。我知道，我们很讨厌他们

---

上面提到的这两点主张对大型系统（和大型遗留存储库）采用更面向组件的方法

使用，您可以在项目中签出它们（即使这是一个两步过程）。但是，您有一些工具可以使子模块管理更容易（例如）

---

当我考虑修复多个项目共享的模块中的一个bug时，我只需修复这个bug并提交它，然后所有人都只需进行更新

这就是我在文章中所描述的“系统方法”：每个人都在处理所有事情的最新情况，并且对少量项目有效。
尽管对于大量模块，“模块”的概念仍然非常有用，但其管理与DVCS不同：

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

• 但是，对于不直接在功能域中的模块，子模块是更好的选择，因为它们引用模块的修复版本（提交）：
  当一个低级框架发生变化时，您不希望它立即传播，因为它会影响所有其他团队，而其他团队将不得不放弃他们为使代码适应新版本所做的工作（您确实希望所有其他团队都知道这个新版本，以便他们不会忘记更新该低级组件或“模块”）。
  这允许您只使用其他模块的官方稳定版本，而不是潜在的未稳定或未完全测试的头

---

至于Mercurial方面，我们还建议将大型遗留CVS/SVN存储库重构为更小的组件。通用代码应该放在自己的库中，然后应用程序代码将依赖于这些组件