颠覆用户的思考:Mercurial术语中的"分支"是什么?

Nei*_*ell 7 mercurial branch dvcs

我是一个Subversion用户,我想我现在已经全身心投入了.所以当然现在我们正在考虑转向Mercurial,我需要重新开始.

在我们的单一存储库,我们有典型branches,tags,trunk布局.当我想创建一个功能分支时我:

  • 使用repo浏览器复制trunkbranches/Features/[FeatureName].
  • 从中查看新的工作副本branches/Features/[FeatureName].
  • 开始研究它.
  • 偶尔提交,合并trunk,解决冲突和提交.
  • 完成后trunk,再合并一次,然后将功能分支"重新整合"为主干.

(请注意,此过程已简化,因为它没有考虑发布候选分支等).

所以我对如何在Mercurial中实现相同的要求(即功能分支而不是在主干上工作)有疑问:

  • 在Mercurial中,仍然是存储库中的分支,还是一个全新的本地存储库?
  • 如果我们每个都有一个整个存储库的副本,这是否意味着我们都拥有彼此各个功能分支的副本(这是很多数据传输)?
  • 我知道Mercurial是一个DCVS,但这是否意味着我们直接推送/拉取更改,而不是通过服务器上的对等存储库?

Wim*_*nen 7

在Mercurial中,仍然是存储库中的分支,还是一个全新的本地存储库?

颠覆工作方式的等价物将是具有多个头部的存储库.然而,这不是惯用的做事方式.通常,在给定的存储库中只有一个头,因此每个分支都有单独的存储库.

如果我们每个都有一个整个存储库的副本,这是否意味着我们都拥有彼此各个功能分支的副本(这是很多数据传输)?

是的,如果您查看本地存储库头部的历史记录,那么您将能够看到所有已合并的功能分支.但是,mercurial存储库非常节省空间.例如,我已经完成了hg clone https://www.mercurial-scm.org/repo/hg获取mercurial本身的源代码,并且在NTFS文件系统上只有34.3 MB(与源代码下载相比,这是1.8 MB).如果您的文件系统支持硬链接,Mercurial也将使用硬链接,因此如果将存储库克隆到同一磁盘上的另一个位置,则几乎没有开销.

我知道Mercurial是一个DCVS,但这是否意味着我们直接推送/拉取更改,而不是通过服务器上的对等存储库?

一种工作方式确实是让每个开发人员公开一个公共存储库,在其中推送他自己的更改.然后所有其他开发人员可以拉出他们想要的东

但是,通常您将拥有一个或多个"祝福"存储库,其中集成了所有更改.然后,所有开发人员只需要从受祝福的存储库中提取.即使你没有明确地拥有这样一个受祝福的存储库,我想人们会像这样自动组织起来,例如所有来自首席开发人员的人.

  • 在我看来,几年前人们更喜欢分支每个回购(并且BOS在红豆书中认可了它),但是hg支持在回购中使用分支机构现在好多了.我个人将bzr切换为hg主要是因为hg支持多头的回购,我更喜欢这种做法. (2认同)

Ted*_*eid 5

史蒂夫·洛什(Steve Losh)关于上面关于mercurial分支的文章太棒了.我还得到了一些关于分支的解释以及DAG如何在我几个月前给出的关于幻灯片分享的演示中的工作.相关幻灯片从幻灯片#43开始.

我认为理解所有提交到同一存储库的存储都存储在DAG(有向无环图)中,并带有一些简单的规则,这有助于揭开正在发生的事情的神秘面纱.

  • 没有子节点的节点是"头"
  • 根节点没有父节点
  • 常规节点具有单个父节点
  • 合并结果的节点有两个父节点
  • 如果合并节点的父节点来自不同的分支,则子节点的分支将从第一个父节点继承

命名分支实际上只是提交中的元数据标签,但实际上与将某些elses工作合并到存储库时发生的匿名分支没有任何不同,或者如果您返回到早期版本然后在那里进行提交一个新的头(你可以稍后合并).

  • +1感谢您分享幻灯片.我认为唯一缺少的是提到'hg移植`.我的大多数svn合并都是维护分支的错误修复的后端,这种合并并不等同于`hg merge`. (2认同)