Version control 修订控制锁定：陪审团还在吗？

当我在线时，似乎每个人都同意在源代码管理中使用独占锁定工作流是一件坏事。我看到的所有新版本控制系统似乎都是为编辑和合并工作流而构建的，许多系统甚至根本不支持独占锁

然而，与我一起工作的每个人都认为独占锁对于任何源代码控制系统来说都是“必须拥有的”，而以任何其他方式工作都将是一场噩梦。就连最近从其他公司招聘的员工似乎也有这种想法

我的问题不是谁是对的。我很确定我会得到什么答案。我的问题是，这件事真的还有争论吗？有没有一个诚实的“支持锁定”阵营会造成严重的后果？是否正在围绕锁定模型推进修订控制的艺术？还是锁定的风扇在鞭打一匹死马

编辑：

---

到目前为止，这些答案很好地解释了为什么独占锁是偶尔使用的一个好特性。但是，我说的是推广一种工作流程，在这种工作流程中，所有文件都使用独占锁。

我喜欢使用选项来独占锁定某些文件

必须具有独占锁，例如，对于二进制文件

对于某些机器生成的非二进制文件（例如，对于Visual Studio项目文件，如果有两个并行更改要合并，它们根本就不能“合并”。

这是我的$0.02

锁定是一种古老的文本代码思想。一旦程序员多次使用合并，他们就会学习并喜欢它的强大功能

锁的有效案例仍然存在

• 图形更改。99%的情况下，您无法合并两个人在同一个图形上工作
• 二进制更新
• 有时，代码可能非常复杂/简单，一次只需要一个人来处理。在这种情况下，使用功能是项目管理的选择

---

如果您认为合并很困难（虽然我们已经走过了很长一段路，但在某些情况下可能会很困难），并且您没有程序员经常想要编辑同一个文件，那么独占锁定并不一定那么糟糕

很明显，我不会在开源项目中使用它们，但在企业界，规则更为严格，你可以走到一个家伙面前说“我可以打破你的锁吗？”，它可以让人们了解他们在做什么，避免冲突，这样以后就不必解决它们了

如果两个人确实需要同时处理一个文件，通常您可以对该文件进行分支，只要该工具明确指出该分支需要重新合并，您就可以这样做并解决任何冲突

---

也就是说，我不想再在独占锁定的世界中工作。

如果您习惯独占锁定，那么很难接受编辑合并工作流

独占锁定有其好处，尤其是对于无法自动合并或根本无法合并的二进制文件（图像、视频等）

但是：独占锁定的需要总是表明另一个问题：项目工作人员之间的良好沟通。独占锁定提供了一个糟糕的替代：它告诉用户其他人已经在处理这个特定的文件——这是他们不需要使用版本控制系统就应该知道的

因为有更好的方法来帮助团队成员之间的沟通，所以大多数（所有？）版本控制系统不再实现独占锁定，或者只是一个简化版本（即锁定，但这些锁定不会强制实施）

---

版本控制系统的工作不是帮助通信。

在最坏的情况下，独占锁定是最好的方法，因此它的存在总是告诉我存在更大的问题

其中一个更大的问题是代码组织不当。在我为一家大型电信公司做的一次咨询工作中，30名团队成员中有8人一直在处理同一个源文件（VB.NET“god”表单）。我们将等待其他人完成他们的工作并释放排他锁（VSS），然后排他顺序中的下一个人将立即锁定文件以应用他们的更改。这花了很长时间，因为他们必须将所有的工作重新整合到新的代码中，直到那时他们才能看到。因为我是新来的，所以我处于最底层，我从来没有被允许检查我的代码更改。我最终找到了项目经理/主管，建议我承担应用程序功能的另一部分。这个项目最终自毁，但我们中的大多数人在意识到这一必然性后离开了。请注意，VSS集成的使用也是这一失败的关键部分，因为它迫使早期获取宝贵的文件锁

因此，一个组织良好的项目几乎不会导致两个人同时处理同一源文件的同一部分。因此，不需要独占锁定

---

另一个更大的问题是将二进制文件放入源代码管理。源代码管理工具不是为处理二进制文件而设计的，这是一件好事。二进制文件需要不同的处理，而源代码管理工具无法支持这种特殊处理。二进制文件必须作为一个整体进行管理，而不是作为部分（行）进行管理。二进制文件往往更稳定/不变。二进制文件往往需要与源代码管理版本控制不同的显式版本控制，通常需要同时提供多个版本。二进制文件通常是从源代码生成的，因此只需要控制源代码（以及生成脚本）。有关二进制友好的存储设计，请参见Maven repositories（但请不要使用Maven本身，而是使用ApacheIvy）。

在像游戏这样的开源项目上，将图像保持在修订控制下是有意义的，而且这些都很好