适用于企业环境的DVCS有多合适？

Question

我已经使用SVN一段时间了，我对它的工作原理感到非常满意（但我不能说我是专家，而且我对分支和合并没有太多帮助）。然而，有机会在一个新团队中加入一些新的实践，所以我想我会看看DVCS，看看它是否值得跳跃。

我工作的公司是一家非常标准的公司，我们都在同一地点（或有时在家里）工作，我们希望保留所有代码的中央商店。

我的问题是：如果您正在使用DVCS创建一个每个人都推动其更改的中央集线器，那么在这种环境中转移到DVCS及其额外开销是否真的有什么好处？

Answer 1

使用DVCS，人们可以维护自己的本地分支，而无需对中央存储库进行任何更改，并在他们认为已经完成时将其更改推送到主存储库。我们的项目存储在SVN存储库中，但我个人使用git-svn来管理我的本地更改并发现它非常有用，因为我们不允许立即提交所有更改（它们必须先由集成商批准）。 / p>

Answer 2

这完全取决于您希望如何处理项目。如果每个人都想在自己的分支上构建，那么分布式环境就很棒。我更喜欢我的工作的中央存储库（在一个小团队中），因为它使开发人员考虑发布我们产品的一个版本。

根据我的经验，我看到很多DVCS用户认为他们自己的更改是他们不必审查的，并且这些用户在将它们合并到他们自己的树之前审查所有其他开发人员的更改。我喜欢将我的更改视为核心产品的更改，因此我在提交之前会检查这些更改。因此，我们试图在整个开发周期中保持产品的稳定性。重构工作正常，因为我们都经常更新。

我认识的几个DVCS用户更喜欢在独立树上处理他们的功能，并将与中央产品的集成留到他们开发的最后阶段。如果该功能是独立的，这样可以正常工作，但我不希望成为必须将所有以这种方式开发的功能与截止日期相结合的人。

如果您经常集成，DVCS与中央VCS没有多大区别，大多数DVCS都支持中央存储库，而越来越多的中央VCS支持以前DVCS独有的几个功能，如离线提交和搁置。

（仅供参考：Subversion 1.8计划进行离线提交）

Answer 3

就个人而言，我觉得这是一个巨大的好处。即使使用中央存储库，DVCS也会将流程从“编辑代码，从中央更新，提交”更改为“编辑代码，提交，推送到中心”。除此之外，这意味着解决冲突的压力要小得多。它还可以鼓励在较小的块中进行开发，因为您不必在每次提交后进行推送。如果你的团队没问题，那就意味着你的个人提交可能会让应用程序处于一种奇怪的状态，只要它在你最终推送到中央仓库时工作。如果它们不合适，只要您使用git（或hg用于{{1}}，IIRC），您仍然可以使用相同的样式进行开发，但之后在将其推送到中央存储库之前，将所有较小的提交压缩为一个较大的提交。

Answer 4

为我使用DVCS的最大好处是我可以提交到我的本地存储库，而无需与其他人共享这些更改。因此，在进行大的改变时，我会做一些小的增量提交，这意味着我可以恢复最后30分钟的工作，或者对昨天工作的版本做一个差异，但是一旦我的所有工作完成，只会推送到中央存储库

我认为这个好处本身值得转向DVCS。

然而，使用DVCS确实需要更多的思考和理解，并使用像SVN或CVS这样的“标准”版本控制系统，因此如果转移到DVCS或您的中央存储库最终将需要考虑培训开销充满了许多不同的分支，人们没有意识到他们正在创造。

Answer 5

你很快就会从Git对Mercurial开始不可避免的战争...... :-)我个人使用Mercurial，但我要说的应该适合所有 DVCS

在我看来，是的，它们适合企业使用。我在我自己的公司使用它们，虽然只有少数开发人员使用它，但如果你担心可扩展性，请查看使用git和mercurial的大型开源项目，例如： Mozilla，Python。

中心枢纽方法效果很好 - 对于颠覆用户来说这是一个熟悉的工作模型，而且你总是有一个“权威”版本。锁定对此的访问并应用任何钩子来强制执行提交策略，之后，开发人员可以自由地使用本地副本工作。

另一个重要的优点是，我发现合并的情况比使用颠覆感更加痛苦。

使用DVCS更棘手的是管理二进制文件 - 您不能像使用subversion一样锁定二进制文件（以及其他文件）。理想的沟通管理。

最后，如果您使用多台PC工作，克隆回购邮件非常适合保持结帐同步。

希望这会有所帮助。 ķ

Answer 6

我认为DVCS的主要好处在于您希望将更改直接推送给其他人（或机器，例如将存储库带回家），而无需通过中央集线器。如果您需要这样做，DVCS绝对是您的选择。如果，如你所说，

  

您正在使用DVCS创建一个中央集线器，每个人都将其更改推送到

那么你并没有真正利用DVCS的主要目的而且我会说SVN就足够了。

P.S。人们还可以提出这样的论点：DVCS鼓励用户更频繁地提交，因为他们可以在他们的个人存储库中这样做，并且只在他们准备好时才发布他们的更改 - 但这可以通过SVN使用分支机构轻松完成，只有“缺点是“正在”个人“提交增加整个存储库的版本号。

Answer 7

即使使用集线器工作流程，DVCS也能让您在本地进行小型提交，只在您需要时合并它们，并在它们准备就绪时进行推送。

使用非DVCS，您将被迫：

1. 在没有提交的情况下完成你的工作，直到它被抛光并且你推动了一个巨大的提交。
2. 随时进行小型提交，每个人都必须经常合并，但合并中间提交会使它们没有任何价值。

如果你探索一个死胡同，没有DVCS：用第一种方法，你不能倒带，你没有承诺回去;第二个，你的提交和他们的恢复必须由其他人毫无意义地合并。

Answer 8

我个人认为DVCS的最大优点是你在合并之前提交（本地），所以如果合并的中途结果比你原先想象的要复杂，那么回到干净状态是微不足道的。失去你的工作。与CVCS相比，您通常必须先成功合并才能提交。

其他优势包括：

• 在家/在客户站点工作变得更容易，因为您不需要网络连接只是为了检查某些内容，如果您等到基地推送更改，则保留历史记录而不是将所有内容都集中到一个更改中。
• 大多数DVCS操作实际上要快得多，因为它们不需要通过网络提取数据
• 有些事情（例如用户设置脚本）可以直接在希望共享它们而不是通过中心位置的开发人员之间直接共享

Answer 9

根据我的经验，有几种方法可以在企业环境中使用DVCS：

• 多站点支持：您已经分离了团队，并且您使用DVCS在每个位置设置不同的“服务器”，因此它们不受底层网络问题的限制（相信我，会有）。过去常常使用Clearcase Multi-site或Wandisco（适用于SVN / CVS）等“大事”，但现在使用DVCS系统非常可行。

• 支持“漫游用户”：你是一个公司。开发人员，但你想在家工作一段时间（或永远）：而不是依靠VPN你可以在你的笔记本电脑上有一个DVCS，然后你可以自由提交，审查，差异，分支和合并，而不是慢由中央服务器。当你在线或回到办公室时，你会同步回来。

• 真正的“分布式开发”：这是极端的情况：每个开发人员都拥有自己的DVCS（就像你在OSS世界中所做的那样）。这将真正取决于团队的技能和动力：如果团队真的想进入它，他们将受益，否则SYSADM的噩梦就是不得不管理一个回购，而是数百个......以及相应的问题。

Answer 10

实际上，在我们的环境中，增加的hg推送比提交到中央svn repo的开销更少。但最大的优点是所有的花花公子和口哨都是mercurial，这对于个人开发者来说非常棒，无论团队规模或工作流程如何。首先，每个wc都是回购的事实很棒，因为你可以更自由地试验而不会污染主回购。然后，有一些功能建立在wc == repo相等：bisect上，以便快速找到bug潜入的修订版，grep，以及grep历史记录，以及缺少的功能来自颠覆，就像终端中的彩色差异一样。

Answer 11

Bazaar VCS可以作为分布式VCS和集中式VCS使用，因此您可以自由选择所需的工作流程。与此同时，当地私人分支机构（人们可以在研究新功能的同时进行实验，同时定期提交进度）是巨大的优势。

此外，在新的更改进入主干之前，DVCS还需要进行强制性代码审查，从而实现自然开发工作流程。这个工作流程（关于SVN）在UQDS article中得到了很好的描述。尽管文章描述了基于SVN的工作流程，但当您使用任何DVCS而不是SVN时，您会发现它更自然，因为在DVCS中，分支和合并是基本的一流操作。