修订控制锁定:陪审团还在吗?

如果您习惯了独占锁定,那么很难接受编辑合并工作流。

独占锁定有其好处,尤其是对于无法自动合并或根本无法合并的二进制文件(图像、视频等)。

但是:对独占锁定的需求总是表明另一个问题:项目工作人员之间的良好通信。独占锁定提供了一个很差的替换:它告诉用户其他人已经在处理那个特定的文件——这是他们不使用版本控制系统就应该知道的。

因为有更好的方法来帮助团队成员之间的沟通,大多数(全部?)版本控制系统不再实现独占锁定,或者只是一个简化的版本(即锁定,但这些锁定不会被强制执行)。

版本控制系统的工作不是帮助进行通信。

我喜欢 选项 以独占方式锁定某些文件。

有排他锁是必要的,例如对于二进制文件。

对于某些机器生成的非二进制文件(例如,对于Visual Studio项目文件,如果有两个并行更改要合并,则这些文件根本不会“合并”),这也是半必需的。

如果您认为合并是困难的(虽然我们已经走了很长的路,但在某些情况下它们可能是困难的),并且您没有程序员经常想要编辑同一个文件,那么排它锁并不一定那么糟糕。

显然,我不会在开源项目中使用它们,但是在公司的世界里,规则更严格,你可以走到一个人面前,说“我能打破你的锁吗?”它使人们了解正在进行的工作并避免冲突,因此以后不必解决这些问题。

如果两个人确实需要同时处理一个文件,那么通常您可以对该文件进行分支,只要工具明确指出需要将分支合并回中,那么您就可以这样做并解决任何冲突。

也就是说,我不想再在一个独占的锁定世界里工作了。

在最坏的情况下,独占锁定是最好的方法,所以它的存在总是告诉我存在更大的问题。

其中一个更大的问题是代码的糟糕组织。在我为一家大型电信公司做的一次咨询工作中,30名团队成员中有8名经常使用同一个源文件(vb.net“god”表单)。我们将等待其他人完成他们的工作并释放独占锁(VSS),然后按优先顺序排列的下一个人将立即锁定文件以应用他们的更改。这花了很长时间,因为他们必须将所有的工作重新整合到新的代码中,而这些代码只有在那时才能看到。因为我是新来的,所以我处于最底层,我从来没有被允许签入我的代码更改。我最终去找项目经理/主管,建议我承担应用程序功能的另一部分。这个项目最终自毁了,但我们大多数人都在意识到这是必然的时候离开了。请注意,使用vss集成也是这一失败的关键部分,因为它强制提前获取宝贵的文件锁。

因此,一个组织良好的项目几乎不应该导致两个人同时处理同一源文件的同一部分。因此,不需要独占锁定。

另一个更大的问题是将二进制文件放入源代码管理。源代码管理工具不是为处理二进制文件而设计的,这是一件好事。二进制文件需要不同的处理,而源代码管理工具不能支持这种特殊的处理。二进制文件必须作为一个整体进行管理,而不是作为部分(行)进行管理。二进制文件往往更稳定/不变。二进制文件往往需要与源代码管理版本不同的显式版本控制,通常同时提供多个版本。二进制文件通常是从源代码生成的,因此只需要控制源代码(以及生成脚本)。有关二进制友好的存储设计,请参阅maven存储库(但请不要使用maven本身,请使用apache ivy)。

锁定的参数非常糟糕。他们基本上说:我们的工具太差了,不能合并,所以我们锁定了。

根据我的经验,两个人经常需要同时处理同一个文件。(大概有一些商店不会发生这种情况,但我有相当多的经验可以借鉴。)

在这些情况下,两个人都需要得到原始文件的副本,完成他们的工作,并合并他们的更改。在非锁定VCS中,这在大多数情况下是自动和准确的。

有了一个锁定的VCS,会有一个人拿到了锁。如果那个人先完成了,那就太好了;如果没有完成,那么另一个人在能够引入变更之前必须等待。例如,有时需要在某人处于长时间变更过程的中间时快速修复错误。一旦第二个人拥有了锁,第二个人需要合并更改,通常是手动的,并签入新版本。有几次,我看到第一个人的变化完全消失了,因为第二个人不需要手动合并。通常,这种合并是仓促进行的,要么是出于对工作的厌恶,要么是出于简单的时间压力。

因此,如果两个人需要同时处理同一个文件,那么非锁定VCS几乎总是更好的。

如果这一点没有出现,而且两个人永远不需要同时处理同一个文件,那么使用哪一个并不重要。

在开源项目(比如游戏)中,将图片保持在修订控制下是有意义的,并且这些图片很容易被锁定(Subversion支持这一点)。对于源文件,最好进入编辑合并工作流程。这并不难,而且在我的经验中提高了生产力。

这是我的0.02美元。

锁定是一种古老的文本代码思想流派。一旦程序员使用了几次合并,他们就会学习并且通常喜欢它的力量。

锁的有效情况仍然存在。

• 图形更改。99%的时候你不能合并两个人在同一个图形上工作。
• 二进制更新。
• 有时,代码可能非常复杂/简单,一次只能由一个人来处理。在这种情况下,使用一个特性是项目管理的选择。

有趣的问题。对我来说,问题不在于是否上锁,而是 多长时间 锁上。在这家商店里,我是少数,因为我 喜欢 合并。我想知道其他人对代码做了什么。所以我要做的是:

• 总是在源树的本地副本中工作。

• 经常针对“官方”代码运行windiff,必要时将更改合并到本地副本。对于合并,我使用一个旧的emacs(epsilon)并将compare buffers命令绑定到一个热键。另一个键说“使这行的其余部分像另一个文件中的一样”,因为许多更改都很小。

• 当我准备好签入更改时,windiff会告诉我需要锁定、签入和解锁哪些文件。所以我把它们锁得尽可能短,比如几分钟。

所以当无畏的领袖说“你签入了你的代码吗?”答案是“我没有退房。”

但正如我所说,我只是其中的少数。

在我看来,人们使用独占锁定的主要原因是它的简单性,而且对他们来说,没有风险。

如果我拥有对一个文件的独占访问权,我就不必尝试理解别人对同一个文件所做的更改。我不必冒着做更改的风险,然后在我登记时必须与其他人合并。

如果我对要更改的文件拥有独占锁,那么我知道当我签入时,我将能够签入一个一致的变更集;这样做对我来说更简单。

合并(特别是自动合并)的另一个方面是回归问题的可能性。如果没有良好的自动化测试,每次进行自动合并时,都可能会出现问题。至少,如果你对某个东西有一个独占锁,那么你要确保在代码签入之前有人在查看它。对某些人来说,这可以降低风险。

排他锁带走的是变化的潜在并行性。你不能让两个人一起处理一个文件。

开源模型(世界上很多人在不同的东西上协作)促进了锁定是不好的观点,但它确实适用于某些团队。它确实避免了真正的问题。我不是说这些问题是无法克服的,但这需要改变人们的行为方式;如果你想改变为非锁定模式,你必须说服他们改变工作方式,这对他们来说可能更难,而且实际上(在他们看来)会增加风险导致回归。

就我个人而言,我不喜欢用锁,但我明白为什么有些人不喜欢它。

处理您的编辑评论。

即使是rcs和sccs(现在大多数运行在unix/linux上的祖父vcs)也允许对文件进行并发编辑访问,我并不是指单独的分支。有了SCC,你可以做到 get -k SCCS/s.filename.c '并获取该文件的可编辑副本--您可以使用一个选项(' -p 'iirc)使其达到标准输出。你可以让其他人也这样做。然后,当到了签入的时候,您必须确保从正确的版本开始,或者进行合并以处理自收集初始版本以来所做的更改,等等。而且这些检查都不是自动的,冲突也不是自动处理或标记的,等等。我没有说这很容易,只是说可以做到。(在这个方案下,在签入/合并过程中,锁只会被保持很短的时间。您仍然有锁——sccs需要它们,rcs可以使用严格的锁进行编译——但只能用于较短的持续时间。但这是一项艰苦的工作——没有人因为这项工作如此艰苦而去做。)

现代风投可以自动或几乎自动处理大部分问题。这是他们与祖先系统相比的巨大力量。因为合并很容易而且几乎是自动的,所以它允许不同的开发风格。

我还是喜欢锁门。我使用的主要工作系统是(IBMRational)AtriaClearCase;对于我自己的开发,我使用rcs(在Y2K左右放弃了scc)。两者都使用锁定。但是ClearCase有很好的工具来进行合并,我们做了大量的合并,尤其是因为在我工作的产品上至少有4个活跃的代码行(即4个主要版本)。一个版本中的错误修复通常适用于其他版本,几乎是逐字的。

因此,仅锁定VCS通常没有足够好的合并功能来鼓励同时编辑文件。更现代的VCS具有更好的合并(和分支)功能,因此在最短的时间内(足以对文件或更高级的系统中的文件进行原子操作)不需要如此强烈的锁定。

这次讨论有点晚了,但对于任何读过并消化过史蒂夫·马奎尔的书的人来说 编写实体代码 一个中心点是让您的工具尽可能多地检测和识别问题。

编译器连续工作12个小时或更长时间后不会感到疲劳,并且会忘记发出语法错误。但是很容易忘记一个手动的步骤,那就是启动一个通信,然后为它付费。

如果需要对二进制文件进行版本控制,则需要某种形式的锁定,以防止(或至少警告)意外覆盖。它必须是任何VCS的基本特性,即使是分布式的。要在DVC中使用这样的功能,可能需要创建一个中央存储库,但这真的很邪恶吗?如果您在任何类型的公司环境中使用DVC,您将拥有一个中央回购来确保业务连续性。