基于我读过的关于版本控制的一些帖子，似乎人们认为版本控制系统中的悲观锁定是一件坏事。为什么？据我所知，它可以防止一个开发人员提交更改，而另一个开发人员已经检出文件，但那又怎么样？如果您的代码文件太大，以至于您不断有多个人同时处理它们，我提交您应该重新组织您的代码。将其分解为更小的功能单元。
并发代码更改的集成是一个单调乏味且容易出错的过程，即使使用良好的版本控制系统提供的工具也可以使其更容易。我想如果可能的话应该避免。那么，为什么悲观的锁定不鼓励？
答案 0 :(得分：14)
答案 1 :(得分：7)
一般取决于您的项目和团队。悲观锁定很好，因为它很容易理解 - 一次一个开发，不需要合并！
然而，关键的坏处就是 - 一次只有一个开发者。我现在有一个同事去现场的情况，在他离开之前，他检查了一切，如果他必须修复任何错误，他可以返回并检查他所有的变化......对他来说很棒，对我和基地的其他开发团队来说很糟糕。
如果你可以绕过你的团队中的悲观锁定那么可以使用它，真的，人们讨厌它的最大原因是它的Visual SourceSafe的默认做法。如果您对合并大量更改没有信心，那么您还有另一个理由可以使用它 - 如果您曾经使用过乐观锁定SCM，并且启动了合并，您将会知道恢复的难度。 / p>
如果你可以处理合并，那么乐观锁定是优越的，我推荐它，但如果你不想使用它，你不必将你的极客卡交给你。
答案 2 :(得分：6)
我看到它一次又一次地发生。开发人员这样做是因为这个过程很烦人：
悲观锁定感觉就像业余时间一样，对不起。
答案 3 :(得分：4)
答案 4 :(得分：3)
如果开发人员无法处理合并和修复冲突，他应该重新接受教育。
即使是小文件也常常会发生冲突，例如JSP（一个人）（Web开发人员）可能会更改布局代码，而其他人可能会更改JSP正在使用的模型的API。
答案 5 :(得分：3)
关于Bob和John的案例，像svn这样的合作系统不会阻止这种情况，只不过是锁定系统。我可以'更新'FooBar.java，它满足我拥有最新版本的svn，然后在本地删除该文件并用我自己的个人副本覆盖它而不考虑基线版本，并检查它，愉快地破坏另一个人的变化。 没有系统，无论是否锁定，都会阻止这种情况发生，因此我甚至没有看到将其纳入辩论的重点。
真正的问题是决定你的平衡是什么
合并错误的可能性 与 人们锁定文件造成的不便锁定或非锁定系统“优越”的概念是无稽之谈。
我使用VSS，在其默认的完全锁定模式下，有6个开发人员，它的工作方式就像
一个梦。偶尔，有人会忘记释放锁定，我们必须将它们追捕或手动打破锁定并在返回时手动合并，但
这是非常小的。我已经看过svn不止一次搞砸了它的自动合并，所以我真的不相信它。当两个人以不能自动合并的方式更改同一文件时，它并不总是标记“冲突”。
相反，我看到人们对VSS的锁不耐烦，编辑他们自己的副本，
并且在其他人的代码的顶部检查它们，我已经看到了
当我上次检查出来之后，当我可能不小心试图检查其他人已经改变过的东西时，svn很容易抓住我。
我的观点是，这不是一个明智的辩论。任何一个系统的成功都降下来了 如何在冲突点发生时管理冲突点，而不是一个系统 或者另一个更好。
答案 6 :(得分：2)
悲观锁定是（个人经验）协作的方式。它有时很容易被良好的团队沟通所取代。只是说“嘿，我会在这几个文件上工作一段时间”。
我已经在2到6人的团队中工作而没有锁定，除了一些通常和必要的合并之外我们从未遇到过问题。
我还在锁定Visual SourceSafe托管项目时工作过一次。这是恕我直言，适得其反。
答案 7 :(得分：1)
软件开发人员总是乐观主义者 - 只要看看他们估算的技巧吧！
在实践中，我们发现冲突是罕见的，不必担心锁定的好处超过偶尔的冲突解决步骤。
答案 8 :(得分：1)
如果您的代码文件太大，以至于您不断有多个人同时处理它们
如果是这种情况，那么'人类'应该负责并协调任何变化。在理想的情况下，如果您的项目管理有任何好处，您很少会遇到尝试更改锁定文件的时间，因为有人会协调一些事情，所以这实际上不会发生。
换句话说，你会知道'Bob'正在对组件X / Y / Z进行大量更改，如果你在组件X中有一个错误修复，你会知道在尝试提交你之前与Bob交谈变化。
正如我所说这是理想的;）
答案 9 :(得分：1)
如果可能发生严重冲突，悲观锁定是一个好主意。对于大多数编程，你不会看到任何严重的冲突，所以悲观锁定是毫无意义的。例如，如果你是：
...否则