版本管理之SVN实践教程：基础篇（8）：lock-modify-unlock

在前面进行冲突的产生和解决的文章中我们接触到了冲突产生的原因和方法，实际上svn中有两种并行开发的模型，如果能够产生冲突，就说明svn具有检测机制确认并行开发的影响，在现代的版本管理工具中也许不算什么，早期的时候这还真是个问题，这篇文章我们将会来看一下svn中的并行开发方式。

copy-modify-merge

从CVS时代就开始广泛使用的这种方式，在前面的例子中也进行了演示，虽然可能没有意识到是这种方式：

这张svn官方推荐介绍文档的说明的图看起来很复杂，其实内容超级简单，上部分（Figure 1.4)想说的是：Harry和Sally在同一基础上取到了一个文件，Sally先修改/Commit了，然后Harry试图修改/Commit结果提示出错了。
Figure 1.5中Harry先进行update取到Sally的修改，在此基础上commit成功。

lock-modify-unlock

除了copy-modify-merge的方式，还有一种方式就是加锁。简单来说，就是加锁-修改-解锁的步骤来解决不同开发者对于资源的互斥操作。

加锁

假设开发用户devuser2首先对某个文件进行加锁操作

[root@platform branches]# cd feature_script/
[root@platform feature_script]# ls
feature_script.sh  trunk-file
[root@platform feature_script]# svn lock feature_script.sh
'feature_script.sh' locked by user 'devuser2'.
[root@platform feature_script]#

开发用户devuser1也试图对此文件进行加锁修改

[root@liumiaocn ~]# svn co svn://192.168.163.129/demo-repo/branches/feature_script/ --username devuser1 --password devuser1pw

-----------------------------------------------------------------------
ATTENTION!  Your password for authentication realm:

   <svn://192.168.163.129:3690> 4fdba69f-3632-49f7-b5ba-d0491223c588

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/root/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? yes
A    feature_script/feature_script.sh
A    feature_script/trunk-file
Checked out revision 13.
[root@liumiaocn ~]# cd feature_script/
[root@liumiaocn feature_script]# svn lock feature_script.sh 
svn: warning: W160035: Path '/branches/feature_script/feature_script.sh' is already locked by user 'devuser2' in filesystem '4fdba69f-3632-49f7-b5ba-d0491223c588'
[root@liumiaocn feature_script]#

可以看到提示信息说提文件已经被用户devuser2所锁定

modify-unlock

使用devuser2用户进行修改然后解锁

[root@platform feature_script]# svn commit -m "add lock-modify-unlock msg"
Sending        feature_script.sh
Transmitting file data .
Committed revision 14.
[root@platform feature_script]#

其他用户的操作

devuser2到目前为止已经操作完毕，这样其他的用户就可以继续进行同样方式的操作了。

[root@liumiaocn feature_script]# svn lock feature_script.sh 
svn: warning: W160042: Lock failed: newer version of '/branches/feature_script/feature_script.sh' exists
[root@liumiaocn feature_script]# 

devuser1试图对此文件进行加锁，结果得到提示此文件存在更新的版本，言外之意是你需要更新一下。在新的版本上进行lock就成功了，这样就可以开始devuser1对此文件的修正了

[root@liumiaocn feature_script]# svn update
Updating '.':
U    feature_script.sh
Updated to revision 14.
[root@liumiaocn feature_script]# svn lock feature_script.sh 
'feature_script.sh' locked by user 'devuser1'.
[root@liumiaocn feature_script]# 

优点 & 局限

优点

使用lock-modify-unlock方式进行团队开发，优点就是非常简单。只需要要求团队成员修改之前已定要lock，修改之后unlock就可以了。

局限

这种方式也会带来一些问题，比如

忘记解锁

团队成员的忘记解锁，甚至此成员已经不在团队甚至公司中了，所以此时往往需要一个管理员的用户来进行解锁。而svn在进行设计的时候也曾经有过很多争议管理员的用户是否应该有权限进行解锁，或者提供类似的工具进行此类操作，但是这种场景是现实中存在的较为常见的。

效率较差

很多时候两个人对同一个文件的操作，修改往往不在一行或者一个函数内，这种逻辑上不冲突的状况对于文件级别来说，工具的判断是较为困难的。但是一旦使用这种方式，就只好等待对方修改完毕进行解锁。

复杂的关联

用户A和用户B需要对文件A和文件B，这就产生了lock操作，用户A锁了文件A的同时，用户B锁住了文件B，两人同时进行了修改，结果发现需要还需要修改对方锁住的文件，更有趣的是发现还有冲突，需要对方先撤销修改和解锁。然后两个用户分属于不同的部门，为了各自的绩效不肯让步这样狗血的剧情虽然只有在小说中才会出现，但是实际情况中类似的由于lock操作产生的各种问题到是时有发生。

使用场景

一般来说lock-modify-unlock方式是会产生额外的沟通成本的。如何选择这两种开发方式呢？

主要方式：copy-modify-merge

整体来说，svn一般使用copy-modify-merge的方式进行操作，使用这种方式有一些假定和前提：比如进行版本管理的对象文件都是可合并的。

辅助方式：lock-modify-unlock

有很多场景使用copy-modify-merge实现起来可能比较困难，这时，lock-modify-unlock可进行辅助，比如：

场景1： 二进制文件的并行操作

如果管理对象文件不能满足copy-modify-merge假定和前提的场景，并行操作可以考虑lock-modify-unlock进行辅助。二进制文件很难进行合并和冲突的检出和管理，使用严格的lock/unlock方式可以降低问题出现的几率。

场景2：提交窗口冻结期

在很多项目中都有季度/月/周的发布窗口时间段，比如每周定例上线定在周五，周一/周二/周三进行代码合并至trunk，为了保障有充分的UAT，周四/周五进行trunk合并与提交的冻结期。这时就可以使用lock对相关的文件基线进行锁定。

场景3：频繁出现的提交覆盖

在团队开发中，由于各种原因，比如新手对于版本管理的意识不足，团队开发意识薄弱，导致经常出现彼此代码覆盖。但是使用lock，多多少少会使得其至少意识到这个文件谁谁谁也在修改中，通过沟通，降低了覆盖的可能性。当然，在合并的时候直接使用自己的代码进行覆盖提交，使用哪种方式都难以判断的。

PS： 虽然这个系列的文章冠以SVN的名称，但是还是希望以集中式版本管理工具svn为代表，来学习和讨论一下分支模型等在项目中如何更好地实践落地。

参考文章

http://svnbook.red-bean.com/en/1.8/svn.basic.version-control-basics.html#svn.basic.vsn-models.copy-merge.dia-1