将遗留代码库从cvs转移到分布式存储库(例如git或mercurial).初始存储库设计所需的建议

Question

介绍和背景

我们正在改变源代码控制系统,我们目前正在评估git和mercurial.总代码库大约有600万行代码,因此不是很大,也不是很小.

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

我们有一个完整代码库的基本文件夹,在该级别下面有几个不同的上下文中使用的各种模块.例如,"dllproject1"和"dllproject2"可以看作完全独立的项目.

我们正在开发的软件是我们称之为配置器的软件,可以根据不同的客户需求进行无休止的定制.总共我们可能有50个不同的版本.但是,他们有一个共同点.它们共享一些必需的模块(mandatory_module1 ..).这些文件夹基本上包含内核/核心代码和公共语言资源等.然后,所有自定义都可以是其他模块(module1 ..)之间的任何组合.

由于我们目前正在使用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中是否有类似的方法来定义别名？

任何其他问题,建议和指示都非常欢迎!

PS.我已经搜索了类似的问题,但并不觉得他们中的任何一个都100%适用于我的情况.

Answer 1

只需快速评论即可提醒您:

• 这些迁移往往提供的机会,重组资源,而不是沿着模块(每一个仓库),而是沿着功能分域(对于同一给定功能结构域的几个模块被放置在同一个版本库).

然后使用子模块作为定义配置的方法.

• Git没问题,但是从Linus自己的承认来看,将所有内容放入一个存储库可能会有问题.

[...] CVS,即它真的最终面向"一次一个文件"模型.

这很好,因为你可以有一百万个文件,然后只查看其中一些文件 - 你甚至都看不到其他999,995文件的影响.

从根本上说,Git从来没有真正看过不到整个回购.即使你稍微限制一些事情(即只检查一部分,或者让历史记录稍微回顾一下),git最终仍然关心整个事情,并传授知识.

因此,如果你强迫它将一切看作一个巨大的存储库,那么git会非常糟糕 .虽然我们可以改进它,但我不认为这部分是可以修复的.

是的,然后是"大文件"问题.我真的不知道如何处理大文件.我知道,我们很害羞.

上述两点主张针对大型系统(以及大型遗留存储库)采用更加面向组件的方法.

使用Git子模块,您可以在项目中签出它们(即使它是一个两步的过程).但是,您可以使用更多的工具来简化子模块管理(例如git.rake).

当我想要修复一个在多个项目之间共享的模块中的错误时,我只是修复了错误并提交了它,所有这些都只是做了更新

这就是我在后供应商分支中描述的"系统方法":每个人都在最新(HEAD)的一切工作,它对少数项目有效.
但是对于大量的模块,"模块"的概念仍然非常有用,但它的管理与DVCS不同:

• 对于密切相关的模块(也称为"在相同的功能域中",如"与PNL相关的所有模块 - 利润和损失 - 或"风险分析",在金融领域中),您需要使用最新的(HEAD)涉及的所有组件.
  这可以通过使用子树策略来实现,而不是为了您在其他子模块上发布(推送)更正,而是为了跟踪其他团队完成的工作
  .Git允许使用额外奖励这种"跟踪"并没有把你的仓库和一个"中央"资料库之间进行,而且还可以把你和其他球队的本地存储库之间进行,允许一个非常快回往复集成和测试之间类似性质的项目.

• 但是,对于不直接在您的功能域中的模块,子模块是更好的选择,因为它们指的是模块的修复版本(提交):
  当低级框架发生更改时,您不希望它被传播瞬间,因为它会影响所有其他团队,然后他们必须放弃他们正在做的事情来调整他们的代码到新版本(你确实希望所有其他团队都知道这个新版本,为了他们不要忘记更新该低级组件或"模块").
  这允许您仅使用其他模块的官方稳定标识版本,而不是可能不稳定或未经过完全测试的HEAD.

Answer 2

至于Mercurial方面,建议还要将大型遗留CVS/SVN存储库重构为更小的组件.应将公共代码放入其自己的库中,然后应用程序代码将依赖于这些库,其方式与它依赖于其他库的方式类似.

Mercurial具有森林扩展,允许您管理"源树"的"森林".使用该方法,您可以将几个较小的存储库组合成一个较大的存储库.使用CVS,您可以做相反的事情:检查大型存储库的一小部分.

我没有亲自使用林扩展,它的页面说应该使用与Mercurial捆绑的版本相比更新版本.但是,它是通过在一个大的组织如Sun使用OpenJDK项目.

根据Mercurial wiki中嵌套存储库页面的设计,目前正在进行将子存储库报告直接添加到Mercurial核心的工作.