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

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

即使使用良好的版本控制系统提供的工具使其更容易,并发代码更改的集成也是一个单调乏味且容易出错的过程.我想如果可能的话应该避免.那么,为什么悲观锁定气馁呢？

使用Source Safe进行游戏并让开发人员休假两周.再加上VSS管理员不在身边.现在你有一个可以发布的修复程序但是你不能因为开发人员而发布

如果您正在处理多个功能和/或错误修复程序.无论你的代码有多小,你仍然会争夺一个中心文件.

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

但是,关键的坏处就是 - 一次只有一个开发者.我现在有一个同事去现场的情况,在他离开之前,他检查了一切,如果他必须修复任何错误,他可以返回并检查他所有的变化......对他来说很棒,对我和基地的其他开发团队来说很糟糕.

如果你能在你的团队中找到悲观的锁定,那么使用它真的很好,人们讨厌它的最大原因是因为它的Visual SourceSafe的默认做法.如果你没有信心合并很多变化,那么你有另一个理由使用它 - 如果你曾经使用过乐观锁定SCM,并且合并了,你就会知道恢复有多难.

如果你可以处理合并,那么乐观锁定是优越的,我建议它,但如果你不想使用它,你不必将你的极客卡交给你.

Bob需要编辑FooBar.java

约翰检查了它的编辑

鲍勃无论如何编辑他的本地副本并将其保存为FooBar.java.bak

当约翰检查他的时,鲍勃检查了它

Bob将FooBar.java.bak复制到它上面并将其检入

约翰重新实现他的功能

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

Bob需要编辑FooBar.java

约翰检查了它的编辑

鲍勃不得不等待他的拇指,直到约翰完成

悲观的锁定感觉像业余时间,对不起.