我最近在工作中讨论过从Subversion切换到像集市这样的DVCS，我想得到别人的意见。
我已经设法将我不愿意这样做变成一个简单的并行。
版本控制可以使用得很好或很糟糕。
版本控制的“光明方面”是当您使用它来跟踪您的更改时，能够在您破坏内容时返回到旧版本，以及当您发布更改以便您的同事可以看到您的工作时正在进行中的
版本控制的“黑暗面”是指你没有正确使用它，所以你没有定期做出“检查点”你的工作，你在本地结账时做了一些改变，而你没有在制作时与他人分享您的更改。
Subversion使光侧和暗侧都相对较硬。所有基础工作都有效，但很少有人真正在Subversion中使用分支（超出标记和发布），因为合并并不简单。 Subversion本身对它的支持很糟糕，有像svnmerge这样的脚本可以让它变得更好，但它仍然不是很好。所以，现在，有了良好的分支和合并支持，越来越像是协作开发的必要性，Subversion并不匹配。
另一方面，“黑暗面”也非常难以理解。您只需要将本地更改偶尔提交到在线存储库，并通过一个您甚至不记得制作的简单编辑来破坏您的代码，您只需要被咬一次。所以你最终定期提交，人们可以看到你正在做的工作。
所以，最终Subversion最终成为一个很好的中间VCS，尽管实施最佳实践有点麻烦，但仍然很难让事情变得非常糟糕。
相比之下，对于DVCS来说，要么完全偏向光边还是暗边要么要低得多。使用这些现代VCS系统，分支和合并更加简单。但是，分布式方面使您可以轻松地在自己的计算机上的一组本地分支中工作，为您提供检查工作所需的细粒度提交，可能无需发布您的更改，以便其他人可以查看，查看和协作。将更改保留在本地分支中而不发布它们的摩擦力通常低于在公共可用服务器上的某个分支中发布它们的摩擦。
简而言之，问题在于：如果我给开发人员提供DVCS，我怎样才能确保他们使用它来进入'轻量级'，仍然定期在中心位置发布他们的变化，以及让他们明白他们不想分享他们一周的本地黑客可能只是其他开发人员在第一个假期时可以用来完成功能的东西？
如果DVCS的光侧和暗侧都很容易到达，我该如何让它们远离黑暗面呢？
答案 0 :(得分：3)
如果您的团队中有开发人员不想分享他们的“一周本地黑客”，那就是问题，而不是您正在使用的源控制工具。你所描述的“黑暗面”的一个更好的术语是为团队编码的“错误方式”。源代码控制是一种用于促进协作工作的工具。如果您的团队不清楚目标是分享工作这一事实，那么使用源代码管理的最佳理由甚至都不适用。
另外，我认为您可能对分布式源代码控制有点困惑。没有发布到中心位置。有些分支比其他分支更重要，并且存在许多分支。牢记这一点，我认为分布式源代码控制确实最适合流行的开源项目。我认为集中式源代码控制对于公司或其他明确定义的实体的开发仍然更好。
答案 1 :(得分：2)
尼克，
虽然我同意问题是“不分享你的工作”，但主要的论点是工具促进了某个工作流程，并非所有工具都适用于所有具有相同摩擦力的问题。我担心的是，DVCS可以让您更轻松地分享您的工作，因为您没有不与SVN共享工作的弊端。如果不共享的摩擦力低于不共享的摩擦力（在DVCS中），开发人员在其他条件相同的情况下可能很容易选择摩擦力最小的路径。
我不认为我对分布式源代码控制感到困惑。我知道默认情况下没有“中心位置”。但是大多数使用DVCS的项目仍然在他们发布的“中心位置”具有“主”分支的概念。出于我的问题的目的，我只区分'私人'（只能由开发人员访问）和'公共'（可由所有其他开发人员访问）分支。
答案 2 :(得分：1)
您区分“私有”和“公共”分支，但这些情况之间唯一真正的区别是分支机构的存储库是仅在本地还是在公司范围内可用。中央存储库只有一种方式可以在整个公司范围内使用。
相反，为什么不说所有存储库必须在整个公司内公开可用？例如，您可以让所有开发人员运行他们自己的本地VCS服务器，并share their branches via zeroconf。
答案 3 :(得分：0)
我认为svn的合并在最新版本中有所改变。