我们是Subversion极客，我们想知道Mercurial的好处[关闭]

看过我是Subversion极客之后，为什么我应该考虑还是不考虑Mercurial或Git或任何其他DVCS。

我有一个相关的后续问题。我阅读了该问题，并阅读了推荐的链接和视频，我看到了好处，但是我没有看到人们在谈论的整体思维转变。

我们的团队由8至10名开发人员组成，他们在一个由60个项目组成的大型代码库中工作。我们使用Subversion并有一个主干。当开发人员启动新的Fogbugz案例时，他们将创建一个svn分支，在该分支上进行工作，完成后，它们将合并回主干。有时它们可​​能会在分支上停留更长的时间，并将中继合并到分支以接收更改。

当我看着Linus谈论人们创建分支而不再做分支时，那根本不是我们。我们每周可能会创建50-100个分支，而不会出现任何问题。最大的挑战是合并，但我们在合并方面也相当出色。我倾向于通过fogbugz case＆checkin合并，而不是合并分支的整个根。

我们永远不会在远程工作，我们永远不会在分支机构之外建立分支机构。如果您是代码库中该部分中唯一的工作人员，则与主干的合并将顺利进行。如果其他人修改了同一段代码，则合并可能会变得混乱，您可能需要进行一些手术。冲突就是冲突，除非有足够的智能来理解代码，否则我看不出大多数系统在大多数情况下如何做到正确。

创建分支后，接下来要检出60k +个文件会花费一些时间，但这对于我们使用的任何源代码控制系统都是一个问题。

我们没有看到的任何DVCS是否有一些好处对我们有很大帮助？

重新表述您的问题，“如果我们仅计划集中使用DVCS，它有什么好处？” 当您这样问时，事实并非如此。在VCS中，每个任务一个分支非常普遍。如果您考虑一下，那么在开发人员的机器上拥有源代码的本地工作副本，并且该工作副本每天都可以独立于主干进行更改，这就是一个分支，即使没有人称呼它。那和您的工作流程之间的唯一区别是，您还要在中央服务器上为这些分支指定一个永久名称。那不是Linus和其他人谈论的那种分支。

要了解DVCS，需要从根本上转变思维。您必须问自己，要与想要的任何人（只有他们共享）共享多少分支，您将要做什么。其中包括只有您自己才能看到的分支。

可能性是无止境。仅举一个例子，两个人在接口的相对侧工作如何？他们需要定期彼此共享代码，但是还不够稳定，无法与所有人共享。他们可以创建一个分支以在彼此之间共享，然后在准备就绪时将其合并回中央存储库。

进行本地本地提交的能力本身值得。那就是您自己必须经历的事情。

自己拥有本地回购所获得的速度也值得。是的，对于任何60k文件存储库，初始克隆在任何VCS中都将不可避免地变慢，但是一旦有了，使用DVCS签出新分支的速度将提高几个数量级。

对于您的特定情况，切换到DVCS没有任何好处。您对现有系统感到满意，它可以满足您的所有需求，那么为什么要切换呢？SVN仍然是一个活跃的开源项目，并且与hg或git相比，与所有主要的IDE和开发工具的集成度更高，更成熟。考虑到您的团队规模和项目数量，您是否真的想花时间在现有工具运行良好的情况下转换为新工具？

如果您的开发人员没有DVCS就无法运行，请将其指向svn网关获取hg或git。向他们清楚表明，他们到svn信息库的签入必须符合团队其余人员使用的所有过程和流程。这种方法的另一个优点是，真正的DVCS狂热者已经在使用网关，而无需告诉您现在可以从壁橱里出来了：-)。

在我看来，您已经在使用一种工作流，该工作流与许多人开始使用DVCS之后采用的工作流非常相似。

从您的角度来看，DVCS将比SVN具有以下重要优势：

• 克隆存储库后，可以在本地执行许多操作。
  • 查看存储库日志并不需要接触svn服务器，因此速度非常快。
  • 同样，切换分支不需要访问服务器，本地克隆也不需要。
• 因为分支只是历史上不同的路径，所以您的存储库不会被任何人创建的每个分支都杂乱无章（我们在SVN中实际上只有发布分支，但是branches目录中仍然包含许多不再相关的子目录）。
  • 在git中，将分支合并回去并删除ref后，您可能永远都不知道它在那里。
  • 在Mercurial中，您可以选择命名分支（在这种情况下，它将永久编码到每个变更集中），也可以只创建未命名的（拓扑）分支，当分支返回（）时它将悄悄地合并到历史中mergedefaulttrunk
• 在SVN中，分支的分支太模糊而无法使用。在git和hg他们只是课程的标准。
• DVCS理解软件开发是DAG，即，当您合并时，最终会得到具有多个父项的变更集。SVN（至少是我使用的版本）并不真正理解这一点。

关于最后一点，你说

冲突就是冲突，除非有足够的智能来理解代码，否则我看不出大多数系统在大多数情况下如何做到正确。

在使用开关hg专门使用svn单独的，然后gitsvn它一直是我的经验，合并是多简单，无故障使用hg，并gitsvn比他们用svn。与svn（至少是我们使用的版本）合并会产生更多冲突，需要手动解决。

在SVN中合并比较困难的原因之一是，对于每行不同的内容，它只为您提供两个选择，

• 您要合并的分支中的文本
• 您要合并到的分支中的文本

而从DVCS进行合并通常会为您提供第三种选择，即

• 您要合并的两个分支的共同祖先的文本

不要小看这有什么好处，它为您提供了比简单的双向diff更好的更改环境。

总而言之，我建议您尝试一下。使用gitsvnand 工具hgsubversion，您甚至可以使用当前的SVN存储库尝试使用它们。

^{注意，首先创建克隆是一个皇家PItA，但是一旦完成，您就可以使用现有的CVCS获得DVCS的大部分功能。}

在这种过渡之后，我注意到了一个重要的变化：我更频繁地切换分支，并且我提交的次数比使用Subversion负担得更多。例如，有许多微小的功能分支按顺序组织，我可以花数月的时间向每个分支添加位，轻松地将它们按顺序重新部署到不断变化的中继中。重新排列功能分支的合并顺序很简单。

但是，实际上，我实际上并未离开Subversion。我只是使用git作为本地svn客户端。