为什么Kiln基于Mercurial而不是其他（D)VCS

Question

作为 FogCreek Kiln 的基础，选择 Mercurial 作为源代码管理系统的原因是什么？它与紧密集成的代码审查和 FogBugz 集成有关吗？

为什么选择 Mercurial 而不是其他（分布式）版本控制系统，例如 Bazaar、Git 或 Monotone？或者像 Fossil（分布式软件配置管理，包括缺陷跟踪和 wiki）一样创建自己的版本控制系统？

是哪些特点使得 FogCreek 选择将 Mercurial 作为 Kiln 引擎？

- Jakub Narębski

---

你的语气听起来好像基于Mercurial是一个大问题一样...那么问题出在哪里？ - Juliano

鉴于Jakub在Git方面有银徽章，我猜这是因为他们没有选择Git。 - deft_code

好的... 我想知道这是不是因为Mercurial具有某些特定的功能/特性（如MS Windows支持、主要使用Python编写、API和扩展生态系统、智能HTTP协议支持）导致的，同时也想知道Git是否可以改进其中的一些功能。 - Jakub Narębski

Git在GitHub上非常受欢迎，所以竞争会很激烈。Mercurial可能是第二受欢迎的。 - JD Isaacks

注意：Kiln支持Git/GitHub，正如我在我的修订答案中提到的那样。 - VonC

Answer 1

以下是一位Kiln开发者提供的答案。

• 它提供了真正的分支功能。
• 易于使用。
• 对Windows的支持非常好。
• 速度快。
• 功能强大。
• 容易扩展。

详细内容请参见此处。他们已经详细地解释了自己的选择。

- deft_code

---

开发人员直接给出解释比纯粹的猜测要好，+1。 - ThisSuitIsBlackNot

除了 Windows 支持之外，Git 也同样不错！ - Ian Ringrose

由于 Windows 支持的原因，Git 的情况并非如此。 - jk.

我也发现从使用Subversion的思维方式来看，相比Git来说更容易上手Mercurial。 - Martijn Heemels

Ian说：“Git也可以这样说（除了Windows支持）”-- 嗯，你似乎忽略了“易于使用”的部分。;-p Git是一个以其自身开发者为目标受众设计用户界面的黄金标准示例。这就像是通过CAN总线适配器和从研发实验室借来的原型测试设备驾驶汽车一样。非常强大，但需要你在汽车行业内。 - Sz.

Answer 2

原始答案（2009年11月，GitHub只有1年，Git只有4年）

我真的不知道，但我会猜测"更好的Windows支持"，因为Windows可能是他们大多数客户基础的主要平台。
Git仍然太过于"Unix/Linux"产品，通过mSysGit只有一个希望的Windows支持。
只需阅读MSysGitHerald文章的语气，如第九篇:

很长一段时间，msysGit由汉尼斯、斯特芬、塞巴斯蒂安·舒伯特和我[Johannes Schindelin]组成的团队推动。在某个阶段，我变得如此沮丧，以至于完全停止了对 msysGit 的工作。原因很简单：它再也不好玩了。太多的人要求修复或增强，并且没有人提供自己的贡献。由于我不是一个Windows人（自1994年以来一直是一名快乐的Linux用户），在mSysGit上的工作对我来说不够有价值，所以我停止了。
但与此同时，情况已经改变了。
我们收到了来自...的贡献

这并不会给你的IT老板带来太多信心。就个人使用而言，我很喜欢Git，并非常感激所有mSysGit贡献者所做的努力，但在大公司中，我将很难使Git成为我们的Windows开发人员所采用的默认DVCS工具。
这不仅因为学习曲线，更主要的是支持水平还没有达到那个程度。
这只是个人意见，如果你有不同的成功部署Git的经验，那就更好了。

Mercurial是最接近Git的DVCS，基于便携式Python脚本（而不是基于linux/unix的sh脚本），可能是一个实用的选择。

---

2018年更新，七年后：是的，Git在Windows上的支持现在已经成为现实。

微软将其整个Windows代码库放入了一个（巨大的）Git存储库中：请参见“地球上最大的Git repo”：3.5M文件，300GB，4,000名工程师每天生产1,760个“实验室构建”，涉及440个分支以及数千个拉取请求验证构建。
但是这是通过添加GVFS（Git虚拟文件系统）实现的，它允许根据您使用的内容动态下载仅需要的部分。
这还不是Git本机支持的功能，尽管其集成已于2017年12月开始实施，实现了窄/部分克隆。

Kiln也宣传其支持Git：

Kiln，我们最佳的分布式版本控制系统托管解决方案，支持Git和Mercurial！GitHub很棒。FogBugz也很棒。那么有什么更好的呢？集成它们怎么样！每当传入的变更集评论中提到一个用例时，GitHub Web Hooks可以通知FogBugz。

- VonC

---

Windows 上的 Git 支持已经存在了相当长的时间。最初，人们必须自己构建它（最好不要忘记清理 2..3 GB 的对象文件）。然而，对于 Windows 的支持仍然是半心半意的，因为您会注意到第一次处理具有大小写不同的引用的遗留存储库时。一旦 Git 尝试解包这些引用（意味着它们变成文件和文件夹名称），您就会遇到麻烦。严格来说，这也不是 Windows 的问题。此外，缺乏 Windows 支持纯粹是经济原因...Git 还有其他问题。 - 0xC0000022L

@0xC0000022L 我同意你的观点，这在2009年就已经成为现实。如今（十年后），由于微软雇用了 Johannes Schindelin (dscho)，正如我在 https://dev59.com/WWUo5IYBdhLWcg3wmQZN#50555740 中提到的那样，Windows 支持已经变得更加具体化。自从微软收购了 GitHub 以来，支持 Git 本身的经济激励更加明确。 - VonC

我非常怀疑。就“瓷器”功能而言，我会同意你的看法。然而，在Git中，“管道”是公共接口的一部分，这使得修复底层问题变得异常困难，比如我在之前评论中提到的未打包引用。提及事情的内部工作原理是一回事，但在Git中，人们期望你了解它并且偶尔愿意亲自动手解决问题。当然，并不是每个人都会遇到这种情况，也许如果只有一个操作系统用于开发，客户端可以警告（未打包引用大小写）的情况。 - 0xC0000022L

@0xC0000022L 确实。我看到在即将发布的 Git 2.23 中仍然对 packed-ref 进行了更新：https://dev59.com/cIPba4cB1Zd3GeqPxMxK#41307509。而且跟踪功能也得到了改进（https://dev59.com/XJrga4cB1Zd3GeqPkEJQ#56094639）。 - VonC

啊，很好。也许随着时间的推移，这些问题将变得微不足道。感谢您的指引。 - 0xC0000022L

@0xC0000022L 说到瓷器和管道...做好准备：https://dev59.com/X2Af5IYBdhLWcg3wsUXT#57066202 - VonC

Answer 3

当我看到分布式版本控制系统时，我喜欢Mercurial，因为:

• Mercurial开发人员似乎关心Microsoft Windows用户。
• Mercurial开发人员不认为Microsoft Windows用户是被迫使用Windows的Unix用户。
• 与许多开源开发者不同，Mercurial开发者似乎并不因为微软盈利而憎恨微软。

也许 Kiln开发人员也有同样的想法...
(所有主要的DVCS系统都足够好，否则其他因素将更加重要)

由于微软拥有GitHub，Git现在在Windows上得到广泛使用，因此这个答案现在已经明显过时了。

- Ian Ringrose

---

事实是，你必须有能力成为一个开源开发者。这可能是因为你仍然和父母住在一起，或者因为你作为一个（技术上的）成年人住在你妈妈的地下室，或者因为你以其他方式赚钱（包括编写专有软件），在所有这些情况下，你仍然必须有能力抽出时间来开发FLOSS。它可能非常有回报，但也可能非常令人沮丧。我认为，广义上讲，FLOSS开发者憎恨微软这一说法不正确。而我开发的 FLOSS 特别是为了 Windows 平台。 - 0xC0000022L

@0xC0000022L 看一下我写答案的日期 - Ian Ringrose

那有什么关系呢？我可以写出完全一样的评论（不过我刚刚注意到我在其中使用了双重否定，这不是我的本意），这种情况十年前也是如此。因为即使在那时，我也是在业余时间开发Windows的FLOSS软件，而同时为一家专营软件（适用于Windows、Linux、Solaris、AIX等操作系统）的供应商工作。 - 0xC0000022L

Answer 4

我不知道FogCreek的情况，但是当我选择使用哪种分布式版本控制系统（DVCS）时，许多人评论说git在Windows上表现不佳（除非在cygwin中运行）。由于据我了解，FogBugz设计可在Windows或Linux系统上运行，因此为了运行git可能需要一个额外的层（cygwin），这可能是决定性因素。我对Bazaar或Monotone了解不多，因此无法提供任何反馈。

- Stephen Newell

---

关于你提到的Linux：Kiln没有Linux客户端，只有Windows和Mac客户端。 - Torben Gundtofte-Bruun

Answer 5

我认为hg与git的问题是一个红鲱鱼，因为仅基于操作系统支持就是一个重大的区别。真正的问题是为什么选择hg而不是bzr，因为这两者非常相似，而且hg开发人员本身认为bzr才是他们真正的竞争对手，反之亦然。Sun在选择OpenSolaris和OpenJDK的DVCS时对两者进行了广泛评估。我们想知道FogCreek选择hg的过程是什么。除了操作系统支持的问题外，我们迄今所获得的答案都是笼统的。

- olefevre

---

四年过去了，Bazaar 似乎只是其曾经的影子。虽然 Mercurial 在不断发展，但 Bazaar 的开发似乎已经停滞不前，尽管在 Breezy 中存在一个友好的分支，而且该分支仍然非常活跃。 - 0xC0000022L

Answer 6

现在他们也加入了Git：

最大的新功能之一是Kiln Harmony，它使您可以使用Git或Mercurial操作Kiln存储库。因此您可以使用Git将更改推送到Kiln存储库，然后使用Mercurial将它们拉回来。这意味着您永远不必决定是否要使用Git还是Mercurial。

- Alexan

---

我认为这个功能可能会让我从GitHub转移到那里。 - Sz.

@Sz。我相信我在某个地方读到了这个确切的功能现在已经被停用了。请参考这里获取一些指针。 - 0xC0000022L