我最近在工作中进行了一些关于从 Subversion 切换到像 bazaar 这样的 DVCS 的讨论，我想听听其他人的意见。
我已经成功地将我的不愿意这样做具体化为一个简单的类比。
Version Control can be used well or badly.
版本控制的“光明面”是当您使用它来跟踪您的更改时，当您破坏内容时能够返回到旧版本，以及当您发布更改以便您的同事可以看到您的工作时 -正在进行中。
版本控制的“黑暗面”是当您没有正确使用它时，您不会通过定期提交来“检查点”您的工作，您会在本地结帐中保留大量更改，并且您不会在您做出更改时与其他人分享您的更改。
颠覆使得光明面和黑暗面都变得相对困难。所有基础功能都有效，但很少有人真正在 Subversion 中使用分支(除了标记和发布之外)，因为合并根本不简单。 Subversion 本身对它的支持很糟糕，并且有像 svnmerge 这样的脚本使其变得更好，但仍然不是很好。因此，如今，良好的分支和合并支持越来越被认为是协作开发的必要条件，而 Subversion 却无法与之匹敌。
另一方面，“黑暗面”也很难遵循。您只需要被咬一次，因为您没有偶尔将本地更改提交到在线存储库，并且通过您甚至不记得做过的简单编辑来破坏您的代码。因此，您最终会定期提交，并且人们可以看到您正在做的工作。
所以，最终 Subversion 成为了一个很好的中间版本 VCS，虽然对于实现最佳实践来说有点麻烦，但仍然很难出错。
相比之下，使用 DVCS 时，无论是完全使用光面还是黑暗面，成本都要低得多。使用这些现代 VCS 系统，分支和合并要简单得多。但分布式方面使得您可以轻松地在自己的计算机上的一组本地分支中工作，为您提供检查点工作所需的细粒度提交，可能无需发布您的更改以便其他人可以查看、审查和协作。将更改保留在本地分支而不发布它们的摩擦通常比在公共(public)服务器上的某个分支中发布它们要低。
简而言之，问题是:如果我为工作中的开发人员提供 DVCS，我如何确保他们使用它走向“光明面”，仍然定期在中心位置发布他们的更改，并且让他们明白，他们不想分享的一周本地黑客可能只是其他开发人员可以在第一个功能度假时用来完成功能的东西？
如果 DVCS 的光明面和黑暗面都很容易触及，我该如何让它们远离黑暗面？
最佳答案
如果您团队中的开发人员不想分享他们的“一周本地黑客”，那么这就是问题所在，而不是您正在使用的源代码控制工具。对于您所描述的“黑暗面”，更好的术语是团队编码的“错误方式”。源代码控制是一种用于促进协作工作的工具。如果您的团队不清楚目标是共享工作这一事实，那么使用源代码控制的最佳理由甚至不适用。
另外，我认为您可能对分布式源代码控制有点困惑。没有发布到中心位置。有些分支比其他分支更重要，并且存在很多分支。记住这一点，我认为分布式源代码控制确实最适合流行的开源项目。我认为集中源代码控制对于公司或其他明确定义的实体的开发来说仍然更好。
关于svn - 您如何处理分布式版本控制系统的光明面和黑暗面？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/27054/