Mercurial还是Git作为Java 12的SCM？ “使用Git代替Mercurial是一个好主意”

JDK团队希望通过Project Skara来研究JDK源代码管理的替代方案，自2008年以来一直在使用Mercurial存储库。

“退休” Mercurial并选择Git是个好主意吗？ 投票表决，看看Java冠军Stephen Colebourne对这次讨论要说些什么。

对于JDK源代码，最有益的替代SCM和代码审查是什么？

• 水银
• 吉特
• 第三方

投票

载入中...

不要错过斯蒂芬·科尔本（Stephen Colebourne）对Skara项目的采访 ：

• 帕特里克·莱因哈特（Patrick Reinhart）：“目前，Git似乎比Mercurial更加工具友好”
• 托马斯·斯蒂夫（ThomasStüfe）：“我认为没有迫切的技术原因可以切换到Git”

JAXenter：您认为将JDK从Mercurial迁移到另一个版本控制系统是一个好主意吗？

Stephen Colebourne：无论您如何看待每个SCM的优点，从开发人员的心智共享角度来看，Git显然已经赢得了Mercurial的支持。 因此，仅考虑将JDK移至最流行，使用最广泛和理解最广泛的SCM平台才有意义。 从我的角度来看，我认为使用Git代替Mercurial是一个好主意。 我看不到要转移到任何其他SCM的情况。

JAXenter：迁移到另一个SCM（比如说Git）会带来什么好处？

Stephen Colebourne： Git的知名度更高，采用更广泛，其相关工具种类繁多。 此外，它还提供了在GitHub或其他中央主机上托管的能力，这往往会提高项目知名度。

还请参见： Skara项目：JDK源代码的下一个SCM将是什么？

JAXenter：这样的举动会引起什么问题？

Stephen Colebourne：项目提交者（我不是）必须调整他们的工具，并有可能学习新的SCM。 源历史记录将被保留，因此这不是问题。

仅考虑将JDK移至最流行，使用最广泛和理解最广泛的SCM平台才有意义。

JAXenter：Git可以替代Mercurial吗？

Stephen Colebourne：不。如果不迁移到Git，JDK最好还是留在Mercurial上。

JAXenter：审核过程如何？ 应该保留在邮件列表中还是应该对其进行更改？

Stephen Colebourne：许多现有提交者都认为，邮件列表上的现有审核过程是一个积极的功能。 我理解这种观点，但是当您不能只在要讨论的确切行中添加评论时，它也会引起误解。 我确实认为，对于大型项目而言，使用GitHub风格的Pull Requests是一个挑战，但是邮件列表也是如此-我还没有看到一个完美的解决方案。

我要说的是，第一步是不更改流程就转到Git。 分开讨论，事情会容易得多。

谢谢！

翻译自: https://jaxenter.com/mercurial-git-scm-java-12-147691.html