代码之家 › 专栏 › 技术社区 › Kristopher Johnson

在大型组织中使用mercurial

dvcs mercurial

Kristopher Johnson · 技术社区 · 15 年前

有一段时间,我一直在为自己的个人项目使用mercurial,我喜欢它。我的老板正在考虑从cvs转向svn,但我想知道我是否应该换成mercurial(或者其他的dvc)。

Mercurial的一个缺点是,它的设计似乎围绕着每个“项目”都有一个单独的存储库的想法。在这个组织中,当前的cvs存储库中有几十个不同的可执行文件、DLL和其他组件,按层次结构组织。有很多通用的可重用组件,但也有一些特定于客户的组件和特定于客户的配置。当前的构建过程通常从CVS存储库中获取一些子树集。

如果我们从cvs迁移到mercurial,那么组织存储库/存储库的最佳方法是什么?我们应该有一个包含所有东西的巨大的mercurial存储库吗?如果不是,那么较小的存储库应该是多细粒度的呢?我认为,如果人们必须从很多不同的地方提取和推送更新,他们会觉得很烦人,但是如果他们必须提取/推送整个公司代码库,他们也会觉得很烦人。

有没有人有这方面的经验或建议?

相关问题:

3 回复 | 直到 7 年前

Vadim Kotov First Zero 7 年前

AFAICS对任何DVCSE的大部分抵抗来自于不了解如何使用它们的人。经常重复的“没有中央存储库”的说法对于那些从很久以前就被锁定在cvs/svn模型中并且无法想象其他任何东西的人来说是非常可怕的,特别是对于那些希望强大的源代码跟踪和再现性(或者如果你也希望这样做的话)的管理层和高级(有经验的和/或愤世嫉俗的)开发人员来说。必须满足关于您的开发过程的某些标准,就像我们在我曾经工作过的地方所做的那样)。好吧,你可以有一个中央“受祝福的”回购协议;你只是没有被它束缚。例如,子团队很容易在其中一个工作站上建立一个内部操场报告。

有很多方法可以剥下这只众所周知的猫的皮,所以坐下来仔细考虑你的工作流程是值得的。想想你目前的实践以及几乎免费的克隆和分支给你的力量。很可能,您目前所做的一些工作已经发展到可以绕过cvs类型模型的局限性;准备好打破这个模型。您可能需要指定一两个冠军,以帮助每个人顺利完成过渡;对于一个大型团队,您可能需要考虑限制提交访问有福 .

在我的工作中(小型软件公司),我们从cvs搬到了hg,再也不回去了。我们主要是集中使用。转换我们的主要(古老的和非常大的)回购协议是痛苦的,但不管你怎么做,当它完成后,它会很容易改变风投。(我们发现了许多情况,其中cvs转换工具只是不知道发生了什么;某人的提交只部分成功,而且他们几天都没有注意到;解决供应商分支;时间似乎倒退导致的一般疯狂和精神错乱,而不是由来自不同时区的本地时间提交时间戳帮助的)。ES)

我发现DVC的最大好处是能够提前提交并经常提交,并且只有在准备好时才推送。当我达到各种正在进行的工作里程碑时,我喜欢在沙地上划出一条线,这样我就可以在需要时返回到某个地方——但这些都不是承诺,应该向团队公开,因为它们显然在无数方面都不完整。(我主要是用易变的队列来完成这项工作。)这都是关于工作流程的;我永远都不可能用CVS来完成这项工作。

我想你已经知道了,但是如果你打算离开简历,你可以做得比SVN好很多。

到单片,还是到模块?无论您使用的是哪种类型的、分布式的还是非分布式的VCS,任何范式转换都将是棘手的;cvs模型在允许您逐个文件提交而不检查其余的repo是否是最新的方面都是非常特殊的(更别提已知会导致模块别名的头痛)。

处理单块存储库可能非常慢。您的VCS客户机必须扫描整个Universe的拷贝以查找更改,而不是只扫描一个模块。(如果您正在使用Linux,那么如果您还没有使用hg inotify扩展,请查看它。)
在提交(推送)时,单一回购也会导致不必要的竞争条件。这类似于cvs最新的检查,但应用于整个repo:如果您有许多活跃的开发人员,经常提交,那么这个会咬到您。

我建议您不要使用单片集成电路,这是值得的,但请注意,它会在构建系统中增加复杂性方面增加自己的开销。(旁注:如果你发现某件事情是一件烦人的琐事,自动完成它!毕竟,我们的程序员是懒惰的生物。)将您的repo拆分为所有组件模块可能太极端了;可能需要找到一个中间层,将相关组件分组到少数存储库中。您可能还会发现研究Mercurial的子模块支持非常有用。- Nested Repositories 以及 Forest Extension (这两个我都应该试着把头转过去)。

在以前的一个工作场所,我们有几十个组件,它们作为独立的CVS模块保存,具有相当规则的元结构。组件声明了它们所依赖的,以及哪些构建部件将被导出到哪里;构建系统会自动编写成片段,以便您正在处理的内容能够获取所需的内容。它通常工作得很好,而且很难不通过CVS的最新检查。(还有一个极其复杂但功能极其强大的构建bot,对依赖性解决的态度是最不费力的:如果已经有一个满足您要求的组件,它就不会重建组件。再加上组装安装程序和整个ISO映像的元组件,您就有了一个很好的方法,可以轻松开始完成构建,并为巫师学徒做准备。有人应该为此写一本书……)

Vadim Kotov First Zero 7 年前

披露:这是一个 cross-post 来自另一个关注git的线程,但我最终还是推荐了mercurial。它一般在企业环境中处理DVC,所以我希望交叉发布它是好的。我对它做了一些修改,以便更好地适应这个问题:

与通常的观点相反,我认为在企业环境中使用DVC是一个理想的选择,因为它支持非常灵活的工作流。我将首先讨论使用dvcs与cvcs,最佳实践,然后特别是关于git。

dvcs vs.cvcs in an enterprise context:

我不会在这里讨论一般的利弊,而是关注你的背景。这是一个普遍的概念,即使用DVC需要一个比使用集中式系统更训练有素的团队。这是因为一个集中的系统为您提供了一种简单的方法来执行您的工作流程,使用分散的系统需要更多的通信和纪律来坚持既定的惯例。虽然这看起来可能会导致开销,但我看到,为了使其成为一个好的过程,增加沟通是必要的。您的团队一般需要就代码、变更和项目状态进行沟通。

在学科背景下的另一个维度是鼓励分支和实验。以下是Martin Fowlers Recent Bliki Entry在版本控制工具上的引用。 < Buff行情>

DVC鼓励快速分支实验。你可以做树枝在颠覆,但事实上他们对所有泄气的人都是可见的从开设分行到实验工作。类似地,DVC 鼓励检查工作点: 提交不完整的更改, 甚至不能编译或通过测试您的本地存储库。你可以再次在中的开发人员分支上执行此操作颠覆,但事实上分支在共享空间中使人们不太可能这样做。

< /块引用>

DVC支持灵活的工作流,因为它们通过定向非循环图(DAG)中的全局唯一标识符而不是简单的文本差异来提供变更集跟踪。这允许他们透明地跟踪变更集的起源和历史,这可能非常重要。

工作流:

Larry Osterman(一个在Windows团队工作的Microsoft开发人员)有一篇关于他们在Windows团队中使用的工作流的伟大博客文章。最值得注意的是,他们有:

一个干净、高质量的代码专用主干(主repo)

所有开发都发生在功能分支上

专题小组有小组休息

它们会定期将最新的主干更改合并到其功能分支中( Forward Integrate )。

完整的功能必须通过几个质量关卡,例如审查、测试覆盖、问答(自行回购)

如果某个功能已完成并具有可接受的质量,则将其合并到主干中( Reverse integrate )。

正如您所看到的,让这些存储库中的每一个都独立存在,您可以将以不同速度前进的不同团队分离开来。此外,实现灵活的质量门系统的可能性也将数字视频控制系统与数字视频控制系统区别开来。您也可以在这个级别上解决您的权限问题。只有少数人可以访问主回购协议。对于层次结构的每个级别,都有一个具有相应访问策略的单独回购。实际上,这种方法在团队层面上非常灵活。你应该让每个团队决定他们是否愿意分享他们的团队回购协议,或者如果他们想要一个更层次的方法,只有团队领导才能承诺团队回购协议。

(图片是从joel spolsky的 hginit.com 中被盗的。)

现在还有一件事要说,即使DVC提供了很好的合并功能,这就是使用连续集成的替代方法。即使在这一点上,您也有很大的灵活性:主干回购的CI、团队回购的CI、Q&A回购等。

Mercurial in an Enterprise Context:

我不想在这里开始一场Git对Hg的火焰大战,你已经在考虑切换到DVC的正确轨道上了。以下是使用Mercurial而不是Git的几个原因:

支持运行python的所有平台

所有主要平台(win/linux/os x)上的优秀GUI工具,一流的合并/vdiff工具集成

非常一致的界面,便于SVN用户进行转换

可以做Git可以做的大部分事情,但提供了一个更清晰的抽象。危险的操作总是明确的。高级功能是通过必须显式启用的扩展提供的。

commercial support is available from seleric.

简而言之,当在企业中使用DVC时,我认为选择一种摩擦最小的工具是很重要的。对于成功的过渡来说,特别重要的是要考虑开发人员之间的不同技能(关于VCS)。

最后,我想向您指出一些资源。Joel Spolsky最近写了一篇文章 a>击败了许多针对dvcs提出的论点。必须提到的是,其他人早就发现了这些相反的论点。另一个很好的资源是Eric Sinks博客,他在那里写了一篇关于企业dvcs障碍的文章。
从另一个专注于Git的线程,但我最终还是推荐了Mercurial。它一般在企业环境中处理DVC,所以我希望交叉发布它是好的。我对它做了一些修改,以便更好地适应这个问题:

与通常的观点相反,我认为在企业环境中使用DVC是一个理想的选择,因为它支持非常灵活的工作流。我将首先讨论使用DVC和CVC,最佳实践,然后特别是关于Git。

企业环境中的DVC与CVC:

我不会在这里讨论一般的利弊,而是关注你的背景。这是一个普遍的概念,即使用DVC需要一个比使用集中式系统更训练有素的团队。这是因为集中式系统为您提供了一种简单的执行使用分散系统的工作流程需要 更多沟通 以及遵守既定公约的纪律。虽然这看起来可能会导致开销,但我看到,为了使其成为一个好的过程,增加沟通是必要的。您的团队一般需要就代码、变更和项目状态进行沟通。

在学科背景下的另一个维度是鼓励分支和实验。这是马丁·福勒最近的一篇闪电式的报道 on Version Control Tools 他发现了对这一现象的非常简明的描述。

DVC鼓励快速分支实验。你可以做树枝在颠覆,但事实上他们对所有泄气的人都是可见的从开设分行到实验工作。类似地,DVC 鼓励检查工作点: 提交不完整的更改, 甚至不能编译或通过测试您的本地存储库。你可以再次在中的开发人员分支上执行此操作颠覆,但事实上分支在共享空间中使人们不太可能这样做。

DVC支持灵活的工作流,因为它们通过定向非循环图(DAG)中的全局唯一标识符而不是简单的文本差异来提供变更集跟踪。这允许他们透明地跟踪变更集的起源和历史,这可能非常重要。

工作流程:

Larry Osterman(一个在Windows团队工作的微软开发人员)有一个 great blog post 关于他们在Windows团队中使用的工作流。最值得注意的是,他们有:

一个干净、高质量的代码专用主干(主repo)

所有开发都发生在功能分支上

特色团队有团队回购

它们确实定期地将最新的主干更改合并到它们的功能分支中。( 正向积分 )

完整的功能必须通过几个质量关卡,例如审查、测试覆盖、问答(自行回购)

如果一个功能完成并具有可接受的质量,它将被合并到主干中。( 反向积分 )

正如您所看到的,让这些存储库中的每一个都独立存在,您可以将以不同速度前进的不同团队分离开来。此外,实现灵活的质量门系统的可能性也将数字视频控制系统与数字视频控制系统区别开来。您也可以在这个级别上解决您的权限问题。只有少数人可以访问主回购协议。对于层次结构的每个级别,都有一个具有相应访问策略的单独回购。实际上,这种方法在团队层面上非常灵活。你应该让每个团队决定他们是否愿意分享他们的团队回购协议,或者如果他们想要一个更层次的方法,只有团队领导才能承诺团队回购协议。

(这张照片是乔尔·斯波斯基的 hginit.com 。)

在这一点上还有一件事要说,即使DVC提供了强大的合并能力,这就是从未使用连续集成的替代方法。即使在这一点上,您也有很大的灵活性:主干回购的CI、团队回购的CI、Q&A回购等。

企业环境中的mercurial:

我不想在这里开始一场Git对Hg的火焰大战,你已经在考虑切换到DVC的正确轨道上了。以下是使用Mercurial而不是Git的几个原因:

支持运行python的所有平台

所有主要平台(win/linux/os x)上的优秀GUI工具,一流的合并/vdiff工具集成

非常一致的界面,便于SVN用户进行转换

可以做Git可以做的大部分事情,但提供了一个更清晰的抽象。危险的操作总是明确的。高级功能通过必须显式启用的扩展提供。

Commercial support is available 来自塞莱恩。

简而言之,当在企业中使用DVC时,我认为选择一种摩擦最小的工具是很重要的。对于成功的过渡来说,特别重要的是要考虑开发人员之间的不同技能(对于VCS)。

最后,我想向您指出一些资源。乔尔·斯波斯基最近写过 an article 驳倒了许多反对数字电视的论据。必须提到的是,其他人早就发现了这些相反的论点。另一个很好的资源是EricSinks博客,他在那里写了一篇关于 Obstacles to an enterprise DVCS .

Community CDub 7 年前

首先,最近关于在大型项目中使用DVC的一些讨论是相关的:

Distributed version control for HUGE projects - is it feasible?

Mercurial的一个缺点是,它的设计似乎围绕着每个“项目”都有一个单独的存储库的想法。

是的,虽然Subversion的标准是拥有一个包含多个项目的整体存储库,但是对于一个DVC,最好拥有更多的粒度存储库,每个组件一个。颠覆有 svn:externals 在签出时聚合多个源树的功能(它有自己的后勤和技术问题)。Mercurial和Git都有一个相似的特性,叫做 subrepos 在汞中。

子repos的想法是每个组件有一个repo,一个可发布的产品(包含多个可重用组件)将简单地引用其依赖的repo。克隆产品repo时,它会带来所需的组件。

我们应该有一个包含所有东西的巨大的mercurial存储库吗?如果不是,那么较小的存储库应该是多细粒度的呢?我认为,如果人们必须从很多不同的地方提取和推送更新,他们会觉得很烦人,但是如果他们必须提取/推送整个公司代码库,他们也会觉得很烦人。

当然可以有一个整体存储库(如果需要的话,甚至可以将其拆分到轨道上)。这种方法的问题更可能归结为发布时间表,以及如何管理不同组件的不同版本。如果您有多个产品,它们自己的发布时间表共享公共组件,那么您最好使用更细粒度的方法,以便于配置管理。

一个警告是,子报告支持是一个相对较新的特性,并不像其他特性那样成熟。具体来说,并不是所有的hg命令都知道子报告,尽管最重要的命令知道。

我建议您执行一个测试转换,并尝试使用子报告支持、组织产品和依赖组件等。我正在做同样的事情,这似乎是一种方法。