2

我最近在工作中讨论了从 Subversion 切换到像 bazaar 这样的 DVCS，我想征求其他人的意见。

我已经设法将我不愿这样做的态度具体化为一个简单的平行线。

版本控制可以用得好也可以用得不好。

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

版本控制的“阴暗面”是你没有正确使用它，所以你没有通过定期提交来“检查”你的工作，你在本地结帐中保留了一堆更改，并且你没有分享你的更改与其他人一起制作。

颠覆使光明面和黑暗面都相对困难。所有的基础都有效，但很少有人真正在 Subversion 中使用分支（除了标记和发布），因为合并一点也不简单。Subversion 本身对它的支持很糟糕，还有像 svnmerge 这样的脚本使它变得更好，但仍然不是很好。因此，如今，随着良好的分支和合并支持越来越被认为是协作开发的必要性，Subversion 无法与之匹敌。

另一方面，“黑暗面”也很难追随。您只需不时不时将本地更改提交到在线存储库，并通过您甚至不记得做过的简单编辑来破坏您的代码，您只需要被咬一次。所以你最终会定期提交，人们可以看到你正在做的工作。

所以，最终 Subversion 最终成为了一个很好的中途 VCS，虽然在实施最佳实践方面有点麻烦，但仍然很难把事情弄错。

相比之下，使用 DVCS，无论是完全进入光明面还是黑暗面的成本都要低得多。这些现代 VCS 系统的分支和合并要简单得多。但是分布式方面可以很容易地在您自己的机器上的一组本地分支中工作，为您提供检查点工作所需的细粒度提交，可能无需发布您的更改，以便其他人可以查看、查看和协作。将更改保留在本地分支中而不发布它们的摩擦通常低于在公共服务器上的某个分支中发布它们。

所以简而言之，问题是：如果我给我们工作中的开发人员一个 DVCS，我如何确保他们使用它去“轻松的一面”，仍然定期在中心位置发布他们的更改，并让他们理解他们不想分享的一周本地黑客可能只是其他开发人员在第一个开发人员度假时可以用来完成功能的东西？

如果 DVCS 的光明面和黑暗面都那么容易到达，我该如何让它们远离黑暗面？

4

4 回答 4

3

如果您的团队中有开发人员不想分享他们的“一周本地破解”，那么这就是问题所在，而不是您使用的源代码控制工具。您所描述的“黑暗面”的一个更好的术语是为团队编码的“错误方式”。源代码控制是用于促进协作工作的工具。如果您的团队不清楚目标是共享工作这一事实，那么使用源代码控制的最佳理由甚至不适用。

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

于 2008-08-25T23:48:56.883 回答
2

缺口，

虽然我同意问题是“不分享你的工作”，但主要论点是工具促进了一定的工作流程，并不是所有的工具都适用于所有具有同等摩擦力的问题。我担心的是，DVCS 使不分享您的工作变得更容易，因为您没有不分享您通过 SVN 获得的工作的缺点。如果不共享的摩擦低于不共享的摩擦（在 DVCS 中），那么在其他条件相同的情况下，开发人员可能很容易选择摩擦最小的路径。

我不认为我对分布式源代码控制感到困惑。我知道默认情况下没有“中心位置”。但是大多数使用 DVCS 的项目仍然在他们发布的“中心位置”有一个“主”分支的概念。不过，出于我的问题的目的，我只区分“私有”（只能由开发人员访问）和“公共”（所有其他开发人员都可以访问）分支。

于 2008-08-25T23:58:28.610 回答
1

您区分了“私人”和“公共”分支机构，但这些情况之间唯一真正的区别是分支机构的存储库是仅在本地还是在公司范围内可用。中央存储库只是实现全公司可用性的一种方式。

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

于 2008-08-26T09:48:55.850 回答
0

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

于 2008-08-25T23:49:44.917 回答