SVN,CVS,VSS工作机制比较

SVN,CVS,VSS不同版本模型工作方式比较

 

VSS:采用 锁定——修改——解锁 模型 。该模型限制太多，用户必须线性单用户工作。并发协作性差，如果两开发人员在同一时刻需要修改同一文件，则只能是等待某一开发人员修改并解锁后，再次从版本服务器获取最新更改并锁定。

CVS:采用 复制——修改——合并 模型。该模型相比VSS有了较大改进，多用户可以同时协作开发。并行性好。多用户可同时获取版本控制服务器上最新的同一文件，建立私用工作副本。并修改各自的副本，最终将各自的副本合并成最终版本。不过麻烦之处就是必须手工核对合并操作的正误。还有就是某些情况（虽然很少）比如需要同时修改一张图片等使得最终合并无法操作的情况，此时VSS的锁定——修改——解锁模型单线工作相对可以解决该问题。

SVN:默认采用CVS 复制——修改——合并 模型。但是自从1.2版本以后同时支持VSS的锁定——修改——解锁工作模式。兼并了两者的长处。

来看看SVN的工作副本是如何跟踪版本库的呢？

1.本地 副本未修改且是最新的。即本地文件中没有修改的内容，且版本控制服务器上也未有对此文件新提交的修改。此时SVN的commit 和update操作都不作任何反应。

2.本地副本已修改且是最新的。即本地文件有修改，但是版本控制服务器上没有对此文件新的提交修改。此时SVN的commit操作会成功提交。update操作不做任何事情。

3.本地副本没有修改且已经过时。即本地文件没有修改，但是版本控制服务器上对此文件已经有新提交修改。此时SVN的commit操作不作任何事情，update操作将会更新副本到最新的版本。

4.本地副本已修改，且也已经过时。即本地文件已经有了修改，且版本控制服务器上的此文件也有人有了新的提交修改。此时commit提交操作失败。需要update操作，获取新版本，此操作会自动智能合并新版本修改和本地版本内容修改。此过程中如果出现冲突，如修改了同一个地方的内容，则此时需要用户手工解决冲突。