根据我读过的几篇有关版本控制的文章，似乎人们认为悲观地锁定版本控制系统是一件坏事。为什么？我知道这会阻止一个开发人员提交更改，而另一个开发人员已将文件检出，但是那又如何呢？如果代码文件太大，以至于我们经常同时有多个人在处理它们，那么我认为我们应该重新组织代码。将其分解为较小的功能单元。

即使使用良好的版本控制系统提供的工具来简化并发代码更改的集成，也是一个乏味且容易出错的过程。我认为应该尽可能避免这样做。那么，为什么不鼓励悲观锁定呢？

解决方案

软件开发人员始终是乐观主义者-只需看看他们的估算技巧即可！

在实践中，我们发现冲突很少见，不必担心锁定会带来的好处胜过偶尔解决冲突的步骤。

• 和Source Safe一起玩，让开发人员休假两个星期。另外，VSS管理员不在身边。现在我们有要发布的修复程序，但是由于开发人员的原因而无法发布
• 如果我们有多个功能和/或者正在修复的错误修复程序。无论代码有多小，我们仍将争用一个中央文件。

悲观锁定是(个人经验)协作的方式。有时，良好的团队沟通可以轻松地代替它。只需说"嘿，我要处理这几个文件一段时间"。

我曾在2至6人的团队中工作，没有锁定，除了一些通常的和必要的合并之外，我们从来没有遇到任何问题。

我还曾经锁定过Visual SourceSafe托管项目。恕我直言适得其反。

• XML文件
• 实用工具
• 减少由于开发人员"意外"签出文件而导致的延迟

如果开发人员无法处理合并和解决冲突，则应该对他进行重新培训。

即使是很小的文件也会发生冲突，例如，与JSP冲突是很常见的，一个人(Web开发人员)可能会更改布局代码，而其他人可能会更改JSP使用的模型的API。

通常取决于项目和团队。悲观锁是好的，因为它很容易一次理解一个开发人员，并且不需要合并！

但是，不好的事情是一次只有一个开发人员。我现在遇到的情况是，一位同事已经到现场，在他离开之前，他检查了所有内容，以便如果必须修复任何错误，他可以返回并检查所有的更改。 ，对我和基地其他开发人员而言都是糟糕的。

如果我们可以绕过团队中的悲观锁定，那么使用它就可以了，实际上，人们讨厌它的最大原因是因为它是Visual SourceSafe的默认做法。如果我们不确定合并许多更改，那么如果我们曾经使用过乐观锁定SCM并提出了合并建议，则还有另一个理由使用它，我们将知道恢复的难易程度。

如果我们能够处理合并，那么乐观锁定将是更好的选择，我建议我们这样做，但是如果我们不想使用它，则不必交出极客卡。

• 鲍勃需要编辑FooBar.java
• 约翰已将其签出以进行编辑
• 鲍勃仍然编辑他的本地副本，并将其另存为FooBar.java.bak
• 当约翰签入时，鲍勃签出
• Bob复制了FooBar.java.bak并将其签入
• 约翰重新实现了他的功能

我已经看到它一次又一次地发生。开发人员这样做是因为此过程很烦人：

• 鲍勃需要编辑FooBar.java
• 约翰已将其签出以进行编辑
• 鲍勃必须等一下，直到约翰做完为止。

悲观的锁定感觉就像业余时间，对不起。

if your code files are so big that you constantly have more than one person working on them at the same time

如果是这种情况，是时候让"人类"负责并协调任何变化了。在理想的情况下，如果项目管理很好，那么我们很少会尝试更改锁定的文件，因为有人会协调事情，所以这几乎不会发生。

换句话说，我们将知道" Bob"正在对组件X / Y / Z进行大量更改，如果我们对组件X进行了错误修复，则在尝试提交更改之前，我们会与Bob交谈。

正如我所说的，这是理想的;)

如果可能发生严重冲突，则悲观锁定是一个好主意。对于大多数编程，我们不会看到任何严重的冲突，因此悲观锁定是毫无意义的。如果我们是以下情况，则例外：

• 在我们无法真正合并的二进制文件上工作-艺术资产(模型，纹理等)就是一个很好的例子。
• 与不了解如何合并并且不希望学习的非技术用户(主要是艺术家，但某些技术作家也会对此进行配合)进行合作。
• 由于高度的复杂性，无法处理非常大的文件，这些文件不易合并或者分解成较小的文件(从未见过像第一手这样的情况，但我相信这是可能的)。

否则...

关于Bob和John的情况，像svn这样的协作系统不会比锁定系统更多地阻止这种情况。我可以"更新" FooBar.java，该文件满足我拥有最新版本的svn的要求，然后在本地删除该文件，并使用我自己制作的个人副本覆盖该文件，而无需考虑基准版本，然后检查并愉快地销毁另一个人的变化。
没有任何系统(无论是否锁定)都无法阻止这种情况，因此我什至看不到将其带入辩论的意义。

真正的问题是决定两者之间的平衡

合并错误的可能性
与
人们锁定文件给我们带来的不便

锁定系统或者非锁定系统都是"高级"的概念是胡说八道。

我已经在6个开发人员的默认完全锁定模式下使用了VSS，它的工作方式就像
一个梦。有时，有人会忘记释放锁，而我们不得不追捕它们或者手动将锁破坏并在它们返回时手动合并，但是
这是非常小的。我已经看到svn不止一次地破坏了它的自动合并功能，因此我并不十分信任它。当两个人以无法自动合并在一起的方式更改了同一文件时，它并不总是标记为"冲突"。
相反，我看到人们对VSS的锁不耐烦，编辑自己的副本，
然后草率地检查其他人的代码，我已经看到
svn会在我不小心尝试检查自上次签出后其他人已更改的某些内容时方便地抓住我。

我的观点是，这不是明智的辩论。两种系统的成功都将失败
冲突点发生时如何管理的方法，而不是一个系统
或者另一个更好。