我是Subversion极客，为什么我应该考虑或不考虑Mercurial或Git或任何其他DVCS？

#1 楼

注意：有关当前问题的答案，请参见“编辑”。首先，阅读Joel Spolsky的Subversion Re-education。我想您的大多数问题都会在那得到解答。

另一个建议是Linus Torvalds在Git上的演讲：http：//www.youtube.com/watch？v = 4XpnKHJAok8。另一个可能还会回答您的大多数问题，而且相当有趣。

顺便说一句，我发现这很有趣：甚至是Brian Fitzpatrick和Ben Collins-Sussman，他们的两个原始创造者subversion在一次Google演讲中表示“对此感到抱歉”，指的是subversion不如水银（和一般DVCS）。一项显着的好处是您可以脱机提交，因为这意味着以下几点：


您不依赖服务器和连接，这意味着速度更快。
成为可以进行Internet访问（或VPN）以进行提交的地方。
每个人都备份了所有内容（文件，历史记录），而不仅仅是服务器。意味着任何人都可以成为服务器。
如果需要，可以强制执行，而不会弄乱别人的代码。提交是本地的。提交时不要踩到对方的脚趾。您不会仅仅通过提交来破坏他人的构建或环境。
没有“提交访问”权限的人可以提交（因为在DVCS中提交并不意味着上传代码），降低了贡献的障碍，您可以决定拉动他们的更改
它可以加强自然沟通，因为DVCS使得这很重要...在颠覆中，您所拥有的提交竞赛反而会迫使沟通，但是会阻碍您的工作。
贡献者可以合作并处理自己的合并，这最终减少了集成商的工作。
贡献者可以拥有自己的分支机构，而不会影响他人的分支机构（但必要时可以共享）。

关于您的观点：


DVCSland中不存在合并地狱；不需要处理。请参阅下一点。
在DVCS中，每个人都代表一个“分支”，这意味着每当更改被提取时就会合并。命名分支是另一回事。
如果需要，您可以继续使用连续集成。恕我直言，这不是必需的，为什么要增加复杂性呢？只需将测试作为您的文化/政策的一部分。
在某些方面，Mercurial更快，而在其他方面，git更快。总的来说，这并不是真正意义上的DVCS，而是具体实现AFAIK。
每个人都将拥有完整的项目，而不仅仅是您自己。分布式事物与您可以在本地提交/更新，从计算机外部共享/获取有关，这称为推/拉。
再次阅读Subversion Re-Education。 DVCS更容易，更自然，但是它们有所不同，请不要以为cvs / svn ===所有版本的基础。

我为Joomla项目贡献了一些文档来帮助宣讲迁移到DVCS，在这里我制作了一些图表来说明集中式与分布式。

集中式



在一般实践中分布



分配到最完整的



在图中您仍然可以看到“集中式存储库”，并且这是集中版本控制爱好者最喜欢的论点之一：“您仍在集中”，不是，您不是，因为“集中”存储库只是大家都同意的存储库（例如，官方github仓库），但这可以改变现在，这是使用DVCS的开源项目（例如，具有大规模协作的项目）的典型工作流程：



Bitbucket.org有点像github上的mercurial，知道它们有无限的私有存储库，具有无限的空间，如果您的团队小于五个，则可以免费使用。

最好的方法说服自己使用DVCS正在尝试DVCS，每位使用svn / cvs的资深DVCS开发人员都会告诉您，这是值得的，并且他们不知道如果没有DVCS，他们将如何生存下来。


编辑：要回答您的第二次编辑，我只想重申一下，使用DVCS时您具有不同的工作流程，我建议您不要寻找因为最佳实践而不尝试的理由。当人们认为没有必要使用OOP时，因为他们可以使用XYZ范式来解决复杂的设计模式；您仍然可以从中受益。

尝试一下，您将看到在“私有分支”中进行工作实际上是一个更好的选择。我可以说出最后一个为什么成立的原因之一是因为您失去了承诺的恐惧，允许您在认为合适的任何时候都可以承诺并以更自然的方式工作。

关于“合并地狱”，您说“除非我们正在试验”，否则我说“即使您正在试验+维护+在修改后的v2.0中同时工作”。正如我之前所说的，合并地狱不存在，因为：


每次提交时都会生成一个未命名的分支，并且每次更改遇到其他人的更改时，都会自然合并。
因为DVCS为每次提交收集更多的元数据，所以在合并期间发生的冲突较少...因此您甚至可以将其称为“智能合并”。
当您遇到合并冲突时，这就是您可以使用：



而且，项目规模也无关紧要，当我从Subversion切换时，我实际上已经在单独工作时已经看到了好处，一切都感觉不错。变更集（不完全是修订版本，而是对包含提交的特定文件的一组特定更改，与代码库的状态隔离开来），您可以直观地看到对特定文件组所做的操作的含义，而不是整个代码库。

关于变更集如何工作以及性能如何提高。我将尝试举一个示例来说明它：从github网络图中显示的svn切换到mootools项目。

之前



之后



您所看到的是开发人员能够在提交时专注于自己的工作，而不必担心破坏他人的代码，他们会担心关于在推/拉之后破坏别人的代码（DVCS：先提交，然后推/拉，然后更新），但是由于合并在这里比较聪明，所以它们通常永远不会做...即使发生合并冲突（这种情况很少见），您只需花费5分钟或更短的时间修复它。

我对您的建议是寻找一个知道如何使用汞/ git的人，并告诉他/她亲自向您解释。通过与一些朋友在命令行上花费大约半小时，同时在我们的台式机和Bitbucket帐户上使用mercurial，向他们展示了如何合并，甚至为他们捏造了冲突，以了解如何在可笑的时间内解决问题，我得以展示

最后，如果您与Windows一起工作，我建议您使用mercurial + bitbucket而不是git + github。 Mercurial还是有点简单，但是git对于更复杂的存储库管理（例如git rebase）更强大。

一些其他推荐读物：


分布式修订控制系统：Git vs. Mercurial vs. SVN
Git vs. Mercurial：请放松

分布式版本控制和Git [第1部分]和分布式版本控制和Git [第2部分]

Git / Mercurial与Subversion：搏斗！
DVCS vs Subversion smackdown，第3轮

为什么我比Git更喜欢Mercurial（第1部分，第2部分）
为Git贡献力量：减少与Git VCS进行开源协作的摩擦

”到目前为止，DVCS为您工作了吗？” -在Joomla上发帖！在Joomla实验性采用了Merurial和git之后，Framework Development邮件列表要求反馈！平台项目

DVCS分支（带有Mercurial）-对DVCS中分支的外观进行了详细的面向示例的介绍，这可能是这些系统中最重要的功能

#2 楼

您要说的是，如果您基本上停留在单个分支上，则不需要分布式版本控制。

是的，但这不是对您的不必要的强力限制一种工作方式，并且无法在多个时区的多个位置进行很好的扩展？中央Subversion服务器应位于何处，如果该服务器由于某种原因关闭，每个人都应该回家吗？

DVCS是Subversion的，Bittorrent是ftp

（从技术上讲，不是合法的）。也许如果您考虑了一下，您可能会理解为什么会有这么大的飞跃？

对我来说，我们切换到git会立即导致


我们的备份更容易执行（只需“ git remote update”就可以完成）
在不访问中央存储库的情况下更易于执行小的步骤。您只需工作，然后在回到托管中央存储库的网络时进行同步。
Fast Hudson构建。因此，使用git pull比更新要快得多。

因此，请考虑为什么bittorrent比ftp更好，然后重新考虑您的位置：）


注意：已经提到在某些情况下ftp比bittorrent更快。这与您喜欢的编辑器维护的备份文件比版本控制系统使用起来更快的方式相同。

#3 楼

分布式版本控制系统的杀手级功能是分布式部分。您无需从存储库签出“工作副本”，而是克隆存储库的整个副本。这是巨大的，因为它提供了强大的好处：


即使在没有Internet访问权限的情况下，您也可以享受版本控制的好处，例如...并夸大其词是DVCS出色的原因-它并不是一个强大的卖点，因为我们许多人发现自己无需Internet就能进行编码的频率开始下雨了。杀手is是，在将提交历史记录推送到主存储库之前，您完全可以控制提交历史记录。

每次都修复了一个错误，并最终得到如下结果：

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

等等。像这样的历史很混乱-确实只有一个修复程序，但是现在实现是在许多包含不想要的工件（例如添加和删除调试语句）的提交之间进行的。对于像SVN这样的系统，替代方案是直到一切正常后才提交（!!!），以保持历史记录的清洁。即便如此，当大量的工作没有受到版本控制的保护时，错误也会流失，墨菲定律正等待残酷地对待您。

拥有您自己的存储库的本地副本，可以在您修复此问题时进行修复可以通过连续滚动“ fix it”和“ oops”提交到“ bug fix”提交来重写历史记录。一天结束时，一个干净的提交将发送到主存储库，如下所示：

r321 Fixed annoying bug.

应采用的方式是这样。

与分支模型结合使用时，重写历史记录的功能更加强大。开发人员可以执行完全独立于分支机构的工作，然后当需要将该分支机构引入主干时，您会遇到各种有趣的选择：


做一个普通的香草合并。将所有东西都带进疣。
重新设定基准。允许您对分支历史进行排序，重新排列提交顺序，将提交扔掉，将提交联接在一起，重新编写提交消息-甚至是编辑提交或添加新的！分布式版本控制系统为代码检查提供了深层支持。

一旦我了解了本地存储库是如何允许我出于对程序员的同情和未来自我的考虑而编辑历史的，我就挂断了电话。 SVN很好。我的Subversion客户端现在为git svn。

允许开发人员和管理人员对提交历史记录进行编辑控制，可以得到更好的项目历史记录，并且可以使用干净的历史记录确实提高了我作为程序员的工作效率。如果所有有关“重写历史记录”的讨论都吓到了您，请不要担心，因为这是中央，公共或主存储库的用途。历史可能（并且应该！）被重新编写，直到有人将其带入其他人正在从中获取的存储库的分支中。那时，历史应该被视为刻在石碑上。

#4 楼

dukofgamings的答案大概是可以得到的，但是我想从另一个方向解决这个问题。

让我们假设您说的是绝对正确的，并且通过应用良好的实践，您可以避免DVCS旨在解决的问题。这是否意味着DVCS不会给您带来优势？人们发臭于遵循最佳实践。人们会搞砸了。那么，为什么您要避免使用旨在解决一系列问题的软件，而选择依靠人们去做一些您可以事先预测出他们不会做的事情呢？

#5 楼

是的，当您必须在Subversion中合并大型提交时，这样做会很痛苦。但这也是一次很棒的学习经历，使您尽一切可能避免合并冲突。换句话说，您学会了经常签入。对于任何共处一地的项目，早期集成是一件非常好的事情。只要每个人都这样做，使用subversion就不会有太大问题。例如，Git是为分散工作而设计的，它鼓励人们从事自己的项目并创建自己的fork。 （稍后）合并。它并不是专门为OP所要求的“小型且高度协作的团队”中的持续集成而设计的。相反，想一想。如果您要做的只是坐在同一个房间里以相同的代码一起工作，那么您将无法使用其精美的分布式功能。

对于一个共同使用CI的团队，我其实，不管您是否使用分布式系统，都没什么大不了的。归结为口味和经验。

#6 楼

因为您应该不断挑战自己的知识。您喜欢颠覆，我可以理解，因为我使用了很多年，对此感到非常高兴，但这并不意味着它仍然是最适合您的工具。

我相信，当我开始使用它时，它是当时的最佳选择。但是随着时间的推移会出现其他工具，现在我更喜欢git，即使对于我自己的业余时间项目也是如此。

Subversion确实有一些缺点。例如。如果您在光盘上重命名目录，则不会在存储库中重命名该目录。不支持文件移动，这使文件移动时执行复制/删除操作，使得在移动/重命名文件时难以合并更改。合并跟踪并不是真正内置于系统中，而是以变通办法的形式实现。

Git确实解决了这些问题（包括自动检测文件是否已移动，您甚至不需要告诉它是事实）。

另一方面hand git不允许您像subversion一样在单个目录级别上分支。

所以我的答案是，您应该研究替代方案，看看它是否比您所熟悉的更适合您的需求，然后决定。

#7 楼

在性能方面，当您必须从一个分支切换到另一个分支，或从一个修订版本跳到另一个修订版本时，Git或任何其他DVCS都比SVN具有更大的优势。由于所有内容都存储在本地，因此比SVN的处理要快得多。

仅此一项就可以让我切换！

#8 楼

而是坚持“通过应用最佳实践，您不需要DVCS”的想法，为什么不考虑SVN工作流程是一个工作流程，却具有一组最佳实践，而GIT / Hg工作流程则是另一个工作流程，具有一组不同的最佳实践。


git bisect（及其对您的主存储库的所有影响）

在Git中，一个非常重要的原则是：可以使用git bisect查找错误。为此，请使用已知运行的最后一个版本，以及已知运行失败的第一个版本，然后（在Git的帮助下）执行二进制搜索以找出导致该错误的提交。为此，您的整个修订历史记录必须相对没​​有其他会干扰您的错误搜索的错误（信不信由你，这实际上在实践中效果很好，Linux内核开发人员一直在这样做）。 />
要实现git bisect功能，您可以在其自己的功能分支上开发一个新功能，对其进行重新设置基础并清除历史记录（因此，历史记录中没有任何已知的无法正常使用的修订版-只是一堆的更改，每项更改都会帮助您解决问题），然后在完成功能后，将其合并到具有工作历史记录的主分支中。

此外，要使此工作生效，规管从哪个版本的主分支开始您的功能分支。您不能仅仅从master分支的当前状态开始，因为那可能有不相关的错误-因此内核社区中的建议是从最新的稳定版本的内核（针对大型功能）开始工作，或者开始最新的带标记的发行候选作品。

您还可以同时将功能分支推送到服务器来备份中间进度，也可以将功能分支推送到服务器与他人共享并在功能完成之前征求反馈，然后再进行操作。将代码转换为项目中每个人*必须处理的代码库的永久功能。

gitworkflows手册页很好地介绍了Git设计的工作流程。也是为什么Git比X更好？讨论了git工作流。

大型分布式项目


为什么我们需要一支具有良好实践和良好经验的高度协作的团队中尉设计习惯？


由于在Linux之类的项目中，涉及的人员如此之多，地理位置如此分散，以至于很难像共享会议室的小型团队那样高度协作。 （我怀疑对于开发像Microsoft Windows这样的大型产品，即使人们都位于同一栋大楼中，团队规模也太大了，无法保持协作水平，而这种协作水平使集中化的VCS无需使用副手即可工作。）

#9 楼

为什么不串联使用它们？在我当前的项目中，我们被迫使用CVS。但是，我们还保留本地git存储库以进行功能开发。这是两全其美的imo，因为您可以尝试各种解决方案并在自己的计算机上保留正在处理的版本。这使您可以回滚到功能的先前版本，或尝试几种方法而不会在弄乱代码时引起问题。拥有中央存储库将为您带来拥有集中存储库的好处。

#10 楼

我没有DVCS的个人经验，但是根据我在这里的答案和一些链接的文档中得出的结论，DVCS和CVCS之间最根本的区别是使用的工作模型。您正在做隔离开发。您正在与其他所有更改隔离地开发新功能/错误修正，直到决定将其发布给团队的其他成员为止。在此之前，您可以进行任何所需的签入，因为没有其他人会对此感到烦恼。
CVCS
CVCS（特别是Subversion）的工作模型是您正在协作发展。您正在与所有其他团队成员直接合作开发新功能/错误修正，所有更改都将立即提供给所有人。
其他差异
svn和git / hg之间的其他差异，例如修订版与变更集是偶然的。很有可能基于修订版本创建DVCS（如Subversion拥有它们）或基于变更集创建CVCS（如Git / Mercurial拥有它们）。
我不推荐任何特定工具，因为它主要是取决于您（和您的团队）最适应的工作模型。
个人而言，使用CVCS不会遇到任何问题。

我不担心检查任何东西，
当我遇到合并地狱时，它处于svn和git / hg都可能发生的情况。例如，当我们开发V3时，某些软件的V2由不同的团队使用不同的VCS维护。有时，必须将错误修正从V2 VCS​​导入到V3 VCS，这基本上意味着要在V3 VCS上进行非常大的签入（所有错误修正都在一个变更集中）。我知道这并不理想，但这是使用不同VCS系统的管理决定。