最近，我在工作中就从Subversion切换到像集市的DVCS进行了一些讨论，我想征询其他人的意见。

我已经设法将自己的不愿意明确化为一个简单的并行。

Version Control can be used well or badly.

版本控制的"轻松方面"是当我们使用它来跟踪更改时，当我们破坏内容时以及在发布更改时能够返回到较旧的版本，以便同行可以看到进行中的工作。

版本控制的"阴暗面"是指我们没有正确使用版本控制，因此我们不会通过定期提交来"检查点"工作，在本地结帐中保留了大量更改，并且不共享更改与其他人交往时就可以与他们交往。

颠覆使亮侧和暗侧都相对较硬。所有基础知识都可以使用，但是很少有人真正在Subversion中使用分支(除了标记和发布之外)，因为合并一点都不简单。 Subversion本身对它的支持很糟糕，并且像svnmerge这样的脚本使它变得更好，但是仍然不是很好。因此，如今，越来越多的人考虑将良好的分支和合并支持视为协作开发的必要条件，因此Subversion无法与之匹敌。

另一方面，"阴暗面"也很难遵循。我们只需一次不让本地更改提交到在线存储库就被咬住一次，并通过甚至不记得进行的简单编辑就可以破坏代码。这样我们就可以进行定期提交，并且其他人可以看到我们所做的工作。

因此，最终，Subversion成为了一个很好的中间VCS，尽管实现最佳实践有点麻烦，但仍然很难使事情变得非常错误。

相比之下，使用DVCS时，完全进入亮侧或者暗侧的成本要低得多。使用这些现代VCS系统，分支和合并要简单得多。但是分布式方面使我们可以轻松地在自己的计算机上的一组本地分支中工作，从而为我们提供了检查工作点所需的精细提交，甚至可能不会发布更改，以便其他人可以查看，查看和协作。将更改保留在本地分支机构中而不发布的做法通常比在公用服务器上的某些分支机构中发布更改的摩擦要小。

简而言之，这就是问题：如果我给工作中的开发人员提供DVCS，我如何确保他们使用它来达到"轻松"的目的，仍然定期将其更改发布在中心位置，并使他们理解他们不愿分享的为期一周的本地黑客可能只是其他开发人员在第一个假期时可以用来完成一项功能的事情？

如果DVCS的亮侧和暗侧都非常容易获得，如何使它们远离暗侧？

解决方案

回答

如果我们团队中的开发人员不想共享他们的"一周本地黑客"，那就是问题所在，而不是我们正在使用的源代码控制工具。我们所描述的"阴暗面"的一个更好的说法是为团队编码的"错误方式"。源代码管理是用于促进协作工作的工具。如果团队不清楚目标是共享工作，那么使用源代码管理的最佳理由甚至都不适用。

另外，我认为我们可能对分布式源代码控制有些困惑。没有发布到中心位置。一些分支比其他分支更重要，并且存在许多分支。记住这一点，我认为分布式源代码控制对于流行的开源项目确实是最有效的。我认为集中式源代码控制对于与公司或者其他明确定义的实体一起进行开发仍然更好。

回答

我相信svn的合并已在最新版本中进行了一些大修改。

回答

缺口，

尽管我同意问题不是"共享工作"，但主要论点是工具可以促进一定的工作流程，并且并非所有工具都适用于所有具有相同摩擦的问题。我担心的是，DVCS使得不共享工作变得更加容易，因为我们没有不共享使用SVN获得的工作的缺点。如果不共享的摩擦小于不共享的摩擦(在DVCS中是这样)，则在其他条件相同的情况下，开发人员可能会轻易选择摩擦最小的路径。

我不认为我对分布式源代码控制感到困惑。我知道默认情况下没有"中心位置"。但是大多数使用DVCS的项目仍然具有从其发布的"中央位置"的"主"分支的概念。但是出于我的问题，我仅在"私有"(仅可由开发人员访问)和"公共"(可由所有其他开发人员访问)分支之间进行区分。

回答

我们可以区分"私人"和"公共"分支，但是这些情况之间的唯一真正区别是分支的存储库仅在本地还是在整个公司范围内都可用。中央存储库只是实现公司范围可用性的一种方法。

相反，为什么不说所有存储库都必须在整个公司范围内公开可用？例如，我们可以让所有开发人员运行他们自己的本地VCS服务器，并通过zeroconf共享他们的分支。