当我在线时似乎每个人都同意在源代码管理中使用独占锁定工作流程是一件坏事.我看到的所有新版本控制系统似乎都是为编辑和合并工作流而构建的,许多甚至根本不支持独占锁.
然而,我与之合作的每个人都认为,对于任何源控制系统来说,排他锁都是"必备",而以任何其他方式工作将是一场噩梦.即使是最近从其他公司招聘的员工也似乎也有这个想法.
我的问题不是谁是对的.我很确定我会得到什么答案.我的问题是,这个问题真的还有争论吗？是否有一个诚实的"亲锁"营地,这是一个严重的案件？是否正在进行任何工作以推进基于锁定模型的版本控制技术？还是锁定风扇鞭打死马？
编辑:迄今为止的答案已经很好地解释了为什么独占锁是一个偶尔使用的好功能.不过,我说的是促进地方独占锁用于工作流的一切.
如果您习惯于独占锁定,则很难接受编辑合并工作流程.
独占锁定有其优点,特别是对于无法自动合并或根本不合并的二进制文件(图像,视频......).
但是:对独占锁定的需求总是表明另一个问题:在项目工作的人之间进行良好的沟通.独占锁定提供了一个糟糕的替代:它告诉用户其他人已经在处理该特定文件 - 他们应该知道这一点而不使用版本控制系统.
由于有更好的方法来帮助团队成员之间的通信,大多数(所有？)版本控制系统不再实现独占锁定或仅实现简化版本(即锁定,但不强制执行这些锁定).
版本控制系统的工作不是帮助沟通.
我喜欢选择独占锁定一些文件[s].
具有独占锁是必要的,例如对于二进制文件.
对于一些机器生成的非二进制文件(例如,对于Visual Studio项目文件来说,它也是半必需的,如果要合并两个并行更改,那么它们就不会很好地"合并").
如果您认为合并很难(虽然我们已经走了很长一段路,但它们可能在某些情况下),并且您没有经常想要编辑同一文件的程序员,独占锁定不一定是那么糟糕.
显然,我不会在开源项目中使用它们,但是在规则更严格的企业界,你可以走到一个人那里说"我可以打破你的锁吗？",它可以让人看到人们是什么努力并避免冲突,以便以后不必解决.
如果两个人真的需要同时处理一个文件,通常你可以分支该文件,只要该工具清楚表明该分支需要合并回来,你就可以做到并解决任何冲突然后.
也就是说,我认为我不想再次在独家锁定世界中工作.
在最坏的情况下,独占锁定是你能做到的最好的,所以它的存在总是告诉我有更大的问题.
其中一个更大的问题是糟糕的代码组织.在我为一家大型电信公司进行的一次咨询演出中,三十位团队成员中有八位一直致力于同一个源文件(VB.NET"上帝"形式).我们会等待其他人完成他们的工作并释放独占锁(VSS),然后啄食顺序中的下一个人将立即锁定文件以应用他们的更改.这需要永远,因为他们必须将他们所有的工作重新整合到他们才能看到的新代码中.由于我是新人,我处于啄食顺序的底部,我从未被允许检查我的代码更改.我最终去了项目经理/主管,并建议我负责应用程序功能的另一部分.该项目最终自毁,但我们大多数人都离开了,因为我们意识到必然性.请注意,VSS集成的使用也是此失败的关键部分,因为它迫使早期获取该宝贵的文件锁.
因此,组织良好的项目几乎不会导致两个人同时处理同一源文件的同一部分.因此,无需独占锁定.
另一个更大的问题是将二进制文件放入源代码控制中.源代码控制工具不是为处理二进制文件而设计的,这是一件好事.二进制文件需要不同的处理,源代码控制工具不能支持这种特殊处理.二进制文件必须作为整体进行管理,而不是作为部件(行)进行管理.二进制文件往往更加稳定/不变.二进制文件往往需要与源代码控制版本控制不同的显式版本控制,通常同时提供多个版本.二进制文件通常是从源生成的,因此只需要控制源(以及生成脚本).请参阅Maven存储库以获得二进制友好的存储设计(但请不要使用Maven本身,请使用Apache Ivy).
京公网安备 11010802040832号 | 京ICP备19059560号-6 