为什么要避免版本控制系统中的悲观锁定?

1. 去玩Source Safe,让开发人员休假两周。此外,VSS管理员不在。现在你有一个修复程序要发布,但由于开发人员的原因,你不能发布
2. 如果你有多个功能和/或bug修复正在进行中。无论你的代码有多小,你仍然会争夺一个中心文件。

这通常取决于你的项目和团队。悲观锁定是好的,因为它很容易理解——一次一个开发,不需要合并!

然而,糟糕的是,每次只有一个开发人员。我现在的情况是,一位同事去了现场,在他离开之前,他检查了所有东西,这样如果他必须修复任何错误,他就可以回来检查他所有的更改……这对他来说很好,对我和基地的其他开发团队来说很糟糕。

如果你能绕过团队中的悲观锁定,那么使用它是可以的,事实上,人们讨厌它的最大原因是它的Visual SourceSafe的默认做法。如果你对合并大量更改没有信心,那么你还有另一个理由使用它——如果你曾经使用过乐观的锁定SCM,并进行过合并,你就会知道恢复有多难。

如果你能处理合并,那么乐观锁定更优越,我会推荐它,但如果你不想使用它,你不必交上你的极客卡。

1. Bob需要编辑FooBar.java
2. 约翰把它检查出来编辑了
3. Bob还是编辑了他的本地副本,并将其保存为FooBar.java.bak
4. 约翰办理入住手续时,鲍勃办理退房手续
5. Bob将FooBar.java.bak复制到上面并签入
6. 约翰重新实现了他的功能

我一次又一次地看到这种情况发生。开发人员这样做是因为这个过程很烦人:

1. Bob需要编辑FooBar.java
2. 约翰把它检查出来编辑了
3. 鲍勃必须等约翰做完才动他的大拇指

悲观的锁定感觉就像业余时间,抱歉。

• 你并不总是有选择 将文件拆分
  • 配置文件
  • XML文件
• 即使是相对较小的文件,也可能包含多个开发人员需要访问的不同部分
  • 图书馆
  • 实用
• 合并工具比以往任何时候都聪明得多
  • 冲突相当罕见
• 减少因开发人员“意外”签出文件而导致的延迟

如果开发人员无法处理合并和修复冲突,他应该接受再教育。

即使是小文件也会发生冲突,例如,对于JSP,一个人(web开发人员)可能会更改布局代码,而其他人可能会更改JSP正在使用的模型的API。

关于Bob和John的情况,像svn这样的协作系统并不能像锁定系统那样阻止这种情况。我可以“更新”FooBar.java,它使svn确信我拥有最新版本,然后在本地删除该文件,并用我自己制作的个人副本覆盖它,而不考虑基线版本,然后签入,愉快地销毁了其他人的更改。 无论是否锁定,没有任何系统可以阻止这一点,所以我认为甚至没有必要将其纳入辩论。

真正的问题是决定你的平衡是什么

合并错误的可能性 vs。 人们锁定文件造成的不便

无论是锁定系统还是非锁定系统都是“优越的”这一概念都是无稽之谈。

我使用了VSS,在默认的完全锁定模式下,有6名开发人员,它的工作原理如下 一个梦。偶尔,有人会忘记解锁,我们不得不追捕他们或手动解锁,并在他们回来时手动合并,但是 这是非常小的。我曾多次看到svn搞砸了它的自动合并,所以我并不真正信任它。当两个人以无法自动合并的方式更改了同一个文件时,它并不总是标记为“冲突”。
相反,我看到人们对VSS的锁不耐烦,编辑自己的副本, 并且草率地将它们检查在其他人的代码之上,我已经看到了 当我可能不小心尝试签入自上次签出以来已被其他人更改的内容时,svn很容易抓住我。

我的观点是,这不是一场明智的辩论。任何一个系统的成功都会下降 当冲突点发生时,你如何管理它们,而不是一个系统是否 或者另一个更好。

悲观锁定(个人经验)阻碍了合作。它有时很容易被良好的团队沟通所取代。只要说“嘿,我要处理这几个文件一段时间”。

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

我也曾尝试过锁定 Visual SourceSafe 托管项目。依我之见,这适得其反。

软件开发人员总是乐观主义者——看看他们的估算技巧就知道了!

在实践中,我们发现冲突很少见,不必担心锁定的好处超过了偶尔的冲突解决步骤。

如果你的代码文件太大,以至于你经常有不止一个人同时处理它们

如果是这样的话,是时候让“人类”负责并协调任何变化了。在理想情况下,如果你的项目管理很好,你很少会遇到试图更改锁定文件的时候,因为有人会协调事情,所以这实际上不会发生。

换句话说,你会知道“Bob”正在对组件X/Y/Z进行大量更改,如果你在组件X中修复了错误,你就知道在尝试提交更改之前要和Bob谈谈。

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

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

• 在无法真正合并的二进制文件上工作——艺术资产(模型、纹理等)就是一个很好的例子。
• 与不知道如何合并且不想学习的非技术用户合作(主要是艺术家,但一些技术作家也会对此感到不满)。
• 处理非常大的文件,由于高度的复杂性,这些文件不容易合并或分解为较小的文件(从未见过这样的情况,但我相信这是可能的)。

否则。..