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

发布于 2024-08-10 20:07:13 字数 375 浏览 8 评论 0原文

选择 Mercurial 作为源代码控制 FogCreek Kiln 基础的原因是什么与紧密集成的代码审查和 FogBugz 集成的管理系统?

为什么选择 Mercurial,而不是其他(分布式)版本控制系统,例如 Bazaar、Git 或 Monotone,或者创建自己的版本控制系统,例如 Fossil(分布式软件配置管理,包括错误跟踪和wiki)做了吗?

哪些特点让 FogCreek 选择 Mercurial 作为 Kiln 引擎?

What were the reason for chosing Mercurial as a basis of FogCreek Kiln, a source control management system with tightly integrated code review, and FogBugz integration?

Why Mercurial, and not other (distributed) version control system, like Bazaar, Git or Monotone, or creating own version control system like Fossil (distributed software configuration management, including bug tracking and wiki) did?

What were features that make FogCreek choose Mercurial as Kiln engine?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

又爬满兰若 2024-08-17 20:07:13

这是一位 Kiln 开发人员的回答。

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

查看完整详细信息 此处。他们自己解释得很彻底。

Here's an answer from one of the Kiln developers.

  • It provides real branching.
  • It's easy to use.
  • Windows support is very good.
  • It's fast.
  • It's powerful.
  • It's easily extensible.

Check out the full details here. They explained themselves quite thoroughly.

甜点 2024-08-17 20:07:13

原始答案(2009 年 11 月,GitHub 只有 1 年,Git 只有 4 年)

我真的不知道,但我会冒险“更好的 Windows 支持”,Windows 可能是大多数客户群的主要平台。
Git 仍然是一个“unix/linux”产品,通过 mSysGit“有希望”的 Windows 支持< /a>.
只需阅读一些
MSysGitHerald 文章的语气,例如 第九个

在很长一段时间里,msysGit 都是由 Hannes、Steffen、Sebastian Schuberth 和我自己 [Johannes Schindelin] 组成的帮派推动的。在某个阶段,我感到非常沮丧,以至于我完全停止了 msysGit 的工作。原因很简单:不再有乐趣了。太多的人要求修复或增强,但没有人提供自己的贡献。由于我不是一个 Windows 用户(自 1994 年以来一直是一个快乐的 Linux 用户),mSysGit 上的工作并没有给我足够的回报让我继续下去。所以我停了下来。
但与此同时,情况发生了变化。
我们得到了...的贡献

在向您的 IT 老板推广该工具时,这并不能激发很大的信心。我对 Git 的个人使用感到非常满意,也非常感谢所有 mSysGit 贡献者的辛勤工作,但在一家大公司,我很难让 Git 成为我们 Windows 开发人员采用的默认 DVCS 工具。
两者都是因为学习曲线,但主要是因为支持水平尚未达到。
这只是个人意见,如果您有成功部署 Git 的不同经验,那么您会更有力量。

Mercurial 是最接近 Git 的 DVCS,并且基于可移植的 Python 脚本(而不是基于 linux/unix 的 sh 脚本),它可能是一个务实的选择。


七年后的 2018 年更新:是的,Windows 对 Git 的支持现已成为现实。

Microsoft 将其整个 Windows 代码库放入一个(巨型)Git 存储库中:请参阅“地球上最大的 Git 存储库":350 万个文件,300GB,4,000 名工程师制作除了数千个拉取请求验证构建之外,还进行了 440 个分支机构的 1,760 个日常“实验室构建”。
但是这是添加了 GVFS(Git 虚拟文件系统) ,它允许根据您的使用动态仅下载您需要的部分。
尽管 它的集成已于 2017 年 12 月开始,并且实现了窄/部分克隆

Kiln 也宣传 Git 支持

Kiln,我们一流的 DVCS 托管解决方案,支持Git 和 Mercurial! GitHub 很棒。 FogBugz 太棒了。什么可以
会更好吗?如何将它们整合起来! FogBugz 可以通过以下方式通知
每当传入的变更集评论提到某个内容时,GitHub Web Hooks
案例。

Original answer (Nov. 2009, GitHub has only 1 years, Git only 4)

I really do not know, but I would venture "better Windows support", Windows being potentially the main platform for most of their client base.
Git is still too much a "unix/linux" product, with a "hopeful" Windows support through mSysGit.
Just read the tone of some of the MSysGitHerald articles, like the ninth one:

For a very long time, msysGit was pushed forward by the gang formed of Hannes, Steffen, Sebastian Schuberth and myself [Johannes Schindelin]. At some stage I got so frustrated that I stopped working on msysGit altogether. The reason is simple: it was no more fun. Way too many people asked for fixes or enhancements, and none of them offered contributions of their own. As I am not a Windows person (being a happy Linux user since 1994), the work on mSysGit was not rewarding enough for me to continue. So I stopped.
But in the meantime, things have changed.
We got contributions by ...

That does not inspire a great deal of confidence when it comes to push forward that tool to your IT boss. I am very happy with Git for a personal usage, and very grateful from the hard work of all mSysGit contributors, but in a big company, I would have a hard time making Git the default DVCS tool adopted by our Windows developers.
Both because of the learning curve, but mainly because the support level is not there yet.
That is only a personal opinion, and if you have a different experience deploying Git successfully, more power to you.

Mercurial being the closest DVCS to Git, and based on portable Python scripts (and not linux/unix-based sh scripts), it may be a pragmatic choice.


Update 2018, seven years later: yes, the Windows support for Git is now a reality.

And Microsoft has its entire Windows codebase into one (giant) Git repository: See "The largest Git repo on the planet": 3.5M files, 300GB, 4,000 engineers producing 1,760 daily “lab builds” across 440 branches in addition to thousands of pull request validation builds.
But this is with the addition of GVFS (Git Virtual FileSystem), which allows to dynamically download only the portions you need based on what you use.
This is not yet in Git native, although its integration has begun last Dec. 2017, with the implementation of a narrow/partial cloning.

Kiln advertises Git support as well:

Kiln, our best-in-class DVCS hosting solution, supports Git as well as Mercurial! GitHub is great. FogBugz is great. What could
be even better? How about integrating them! FogBugz can be notified by
GitHub Web Hooks whenever an incoming changeset comment mentions a
case.

深海夜未眠 2024-08-17 20:07:13

当我查看 DVCS 系统时我喜欢 Mercurial,因为。

  • Mercurial 开发人员似乎很关心 Microsoft Windows 用户。
  • Mercurial 开发人员并不认为 Microsoft Windows 用户是被迫使用 Windows 的 Unix 用户。
  • 与许多开源开发人员不同,Mercurial 开发人员似乎并不讨厌微软赚钱。

也许 Kiln 开发人员也这么认为......
(所有主要的 DVCS 系统都足够好,否则其他因素会发挥更多作用)

这个答案现在显然已经过时了,因为 Microsoft 拥有 github 并且 git 现在在 Windows 上非常普遍使用。

When I looked at DVCS system I like Mercurial because.

  • The Mercurial developers seems to care about Microsoft Windows users.
  • The Mercurial developers do not thinks of Microsoft Windows users as being Unix users that are forced to use Windows.
  • Unlike a lot of open source developers, the Mercurial developers don't seem to hate Microsoft for making money.

Maybe the Kiln developers thought the same...
(All the main DVCS systems are good enough, otherwise other factors would come into play more)

This answer so now clearly out of date as Microsoft owns github and git is now in very common use on Windows.

傻比既视感 2024-08-17 20:07:13

我不能代表 FogCreek,但我知道当我选择使用哪个 DVCS 时,很多人评论说 git 在 Windows 上运行得不好(除非它在 ​​cygwin 中运行)。由于 FogBugz 被设计为在 Windows 或 Linux 系统上运行(据我所知——我自己不是用户),因此有一个额外的层(cygwin)来运行 git 可能是决定因素。我对 Bazaar 或 Monotone 不太了解,所以我无法在那里提供任何反馈。

I can't speak for FogCreek, but I know when I was choosing which DVCS to use many people commented that git does not work well on Windows (unless it's run in cygwin). Since FogBugz is designed to run on either Windows or a Linux systems (from what I understand--I am not a user myself) having an extra layer (cygwin) to run git may have been the determining factor there. I don't know much about Bazaar or Monotone, so I can't offer any feedback there.

子栖 2024-08-17 20:07:13

我认为 hg 与 git 的问题是一个转移注意力的问题,因为操作系统支持问题本身就是一个主要区别。真正的问题是为什么 hg 而不是 bzr,因为这两者非常相似,hg 开发人员自己认为 bzr 是他们真正的竞争对手,反之亦然。 Sun 在为 OpenSolaris 和 OpenJDK 选择 DVCS 时对两者进行了广泛的评估。人们想知道 FogCreek 采摘汞的过程是怎样的。到目前为止,我们得到的所有答案(除了操作系统支持问题)都是笼统的。

I think the issue of hg vs. git is a red herring, as the OS support issue alone is a major difference. The real question is why hg rather than bzr, as these two are very similar and hg developers themselves consider bzr to be their real competition and vice-versa. Sun conducted an extensive evaluation of both when it came to choosing a DVCS for OpenSolaris and OpenJDK. One would like to know what was the process used for picking hg at FogCreek. All we got so far by way of answers (apart from the OS support issue) are generalities.

巴黎夜雨 2024-08-17 20:07:13

所以现在他们还添加了 git:

最大的新功能之一是 Kiln Harmony,它可以让您
使用 Git 或 Mercurial 在 Kiln 存储库上进行操作。所以你可以
使用 Git 将更改推送到 Kiln 存储库,然后使用
善变的。这意味着您永远不必决定是否想要
使用 Git 或 Mercurial。

So now they add also git:

One of the biggest new features is Kiln Harmony, which lets you
operate on Kiln repositories using either Git or Mercurial. So you can
push changes to a Kiln repo using Git and then pull them using
Mercurial. This means that you never have to decide whether you want
to use Git or Mercurial.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文