14

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

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

4

10 回答 10

14
  1. 去玩 Source Safe，让开发人员休假两周。再加上 VSS 管理员不在身边。现在你有一个修复要发布但你不能因为开发人员
  2. 如果您正在处理多个功能和/或错误修复。无论您的代码被分解得多么小，您仍然会争用中央文件。
于 2008-09-26T16:08:27.873 回答
7

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

然而，坏事恰恰是——一次只有一个开发者。我现在有一个同事去现场的情况，在他离开之前，他检查了所有内容，以便如果他必须修复任何错误，他可以返回并检查他的所有更改......对他来说很好，对我和基地的其他开发团队来说很糟糕。

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

如果您可以处理合并，那么乐观锁定是优越的，我会推荐它，但如果您不想使用它，则不必交出您的极客卡。

于 2008-09-26T16:17:18.803 回答
6
  1. Bob 需要编辑 FooBar.java
  2. 约翰已将其签出以进行编辑
  3. Bob 还是编辑了他的本地副本并将其保存为 FooBar.java.bak
  4. 当约翰签到时，鲍勃签了
  5. Bob 在其上复制 FooBar.java.bak 并将其签入
  6. 约翰开始重新实现他的功能

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

  1. Bob 需要编辑 FooBar.java
  2. 约翰已将其签出以进行编辑
  3. 鲍勃必须等到约翰完成后才开始玩弄他的拇指

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

于 2008-09-26T16:32:59.983 回答
4
  • 您并不总是可以选择将文件分开
    • 配置文件
    • XML 文件
  • 即使是相对较小的文件仍可能包含多个开发人员需要访问的不同部分
    • 图书馆
    • 实用程序
  • 合并工具比以往任何时候都更智能
    • 冲突相当罕见
  • 减少由于开发人员“意外”签出文件而导致的延迟
于 2008-09-26T16:12:27.617 回答
3

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

即使是小文件也很常见，例如对于 JSP，一个人（Web 开发人员）可能会更改布局代码，而其他人可能会更改 JSP 正在使用的模型的 API。

于 2008-09-26T16:13:15.070 回答
3

关于 Bob 和 John 的案例，像 svn 这样的协作系统并不能像锁定系统一样阻止这种情况。我可以“更新” FooBar.java，它满足 svn 我拥有最新版本，然后在本地删除该文件并用我自己制作的个人副本覆盖它，而不考虑基线版本，然后签入，愉快地销毁另一个人的变化。没有任何系统，无论是否锁定，都可以防止这种情况发生，所以我什至看不到将其带入辩论的意义。

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

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

锁定或非锁定系统是“优越”的概念是无稽之谈。

我已经在默认的完全锁定模式下使用了 VSS，有 6 个开发人员，它的工作就像做梦一样。有时，有人会忘记释放锁，我们必须手动寻找或破坏锁并在他们返回时手动合并，但这非常少。我不止一次看到 svn 搞砸了它的自动合并，所以我不太相信它。当两个人以无法自动合并在一起的方式更改同一个文件时，它并不总是标记“冲突”。
相反，我看到人们对 VSS 的锁感到不耐烦，编辑自己的副本，并草率地将它们签入到其他人的代码之上，而我

My point is, this is not a sensible debate to have. The success of either system comes down to how you manage the conflict points when they occur, not whether one system or the other is better.

于 2010-04-15T21:29:10.233 回答
2

悲观锁定是（个人经验）协作方式。它有时很容易被良好的团队沟通所取代。只需说“嘿，我将在这几个文件上工作一段时间”。

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

我也曾经锁定过一个Visual SourceSafe托管项目。恕我直言，这适得其反。

于 2008-09-26T16:09:34.987 回答
1

软件开发人员总是乐观主义者——看看他们的估计技能！

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

于 2008-09-26T16:08:01.883 回答
1

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

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

换句话说，您将知道“Bob”正在对组件 X/Y/Z 进行大量更改，如果您在组件 X 中有错误修复，您将知道在尝试提交更改之前与 Bob 交谈。

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

于 2008-09-26T17:28:32.907 回答
1

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

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

除此以外...

于 2008-09-28T02:24:34.483 回答