VSS与SVN比较
引言软件的开发是一个庞大的工程，这样一个庞大的工程，一个人是肯定完成不了的，需要依靠一个团队的努力。而在团队开发的编码过程中，一直存在这样一个难题让开发者头痛不已，即如何协调各自修改的代码。比如，一个开发者修改了某个文件，而其他开发者处得不到更新，就有可能造成团队中有多个版本或者重复开发。再如，两位开发者同时修改一个文件，而开发者之间又往往不知道是否有伙伴也在修改，这样，后提交的往往就会把前一位开发者的结果覆盖掉，从而造成问题。
为了解决团队编码的问题，版本控制软件（Revisioncontrol）应运而生，而在发展过程中，涌现出了很多不同的解决方案。本文便旨在比较VSS与SVN这两种模式对于版本控制问题的不同解决思路。
待比较对象简介：
VSS（Visual Source Safe）：业界大佬Microsoft出品，秉承着微软一贯的界面友好、收费、闭源的特征出现在市场上。笔者分析时使用的是Visual Source Safe 2005版本。
SVN（Subversion）：在CVS的基础上发展而来，开源，因此有很多使用此模式的二次开发后的软件。传说目前大多数开源软件都使用SVN作为版本控制软件。笔者分析时服务器使用的是Visual SVN，客户端则使用TortoiseSVN。
功能比较：
对于冲突的不同解决方案：
VSS：
在VSS2005中，提供了两种数据的控制模型：Lock-Modify-Unlock（独占工作模式）和与SVN相同的Copy-Modify-Merge（并发工作模式）两 种，在本文主要讨论VSS特色的Lock-Modify-Unlock（独占工作模式）。
在Lock-Modify-Unlock模式中，是通过避免冲突的方式来处理的。开发者可以通过Get Latest Version来获取最新版本的文件。而如果想要修改某文件，则需要首先Check-Out（迁出）此文件，迁出时文件自动更新，此时文件处于Lock（锁定）状态，其他开发者无法再次Check-Out，但可以通过Get Latest Version获取当前文件。开发者修改（Modify）完成后，进入VSS客户端，对文件执行Check-In（迁入）操作，文件便进入Unlock状态，此时，其他开发者可以进行Check-Out ， Modify ，Check-In 操作了。
在Lock-Modify-Unlock模式下，一个文件一个时间点上只有一个人有权利修改并提交，因此，不会出现多个开发者同时修改一个文件的情况，也就不会有编码冲突，因此，Lock-Modify-Unlock模式是一种避免冲突的方式。
VSS客户端界面图（红色方框内为提供的功能）：
SVN：
SVN系统使用的Copy-Modify-Merge工作模式，与Lock-Modify-Unlock的避免冲突相对，是一种允许冲突，然后解决冲突的方法。
开发者首先配置SVN Server，Server配置好之后，即可通过客户端获取。客户端获取的是服务器上文件的副本，本地的修改只有在提交（Commit）之后才会更改服务器上的文件。即每个开发者电脑上都会有一个版本文件的副本，且未必是最新的。
正如聪明的你所想到的，不同的人可以修改不同版本的同一文件，并且都可以提交修改，这里面必定有冲突，那么冲突如何解决呢，本文在此重点讨论一下：
当你提交修改时，SVN会检测你修改的文件版本号是不是最新的，如果是，则提交修改，如果不是，则会让你将你所做的更改与服务器上的最新版本合并与解决版本之间的冲突。
处理冲突逻辑很简单，但基本可以处理所有冲突的情况：
比如，两位开发者同时修改一个文件的同一版本并提交修改，SVN可以检测到冲突并处理。因为，必有一人提交时间靠前，提交靠后的开发者提交时SVN会检测版本号，发现文件不是最新的，SVN便下载最新版，然后提示用户合并代码并解决冲突。
再如，一名开发者一个月前获取了版本号为3的文件A，之后出差一个月，回来后提交，一个月时间中，团队在不断完善文件A，此时文件A的版本号为30。在这种情况下，SVN也可以检测到冲突并处理，不会出现覆盖或者放弃之前修改的情况。处理过程如下：出差的开发者修改后的版本号为4，并不是期待版本号31，因此，从SVN便下载最新版，然后提示用户合并代码。
其他情况，也能按这种逻辑处理。
TortoriseSVN右键提供的主要功能：
TortoriseSVN解决冲突处理的界面：
访问权限控制：
VSS：Windows自身的用户账户进行权限控制
SVN：支持Windows自身的用户账户进行权限控制及自身控制访问的方式
一点思考：
笔者的水平下，虽然也可以理解Windows的用户帐户权限控制，但认为这种方式并不直观。与之相对，SVN所支持的自身控制访问清晰、明了，如果只是限制用户是否可以读写，不再需要其他复杂权限设定，笔者更推崇SVN。
重命名问题：
经过测试，VSS2005是不支持文件改名的。迁出后，如果改名，当迁入时，将会报告错误：“没有找到某文件”，包括VSS提供的Copy-Modify-Merge模式。
而SVN模式下，文件重命名后提交，服务器是可以识别原来的文件改名了。
一点思考：
在代码开发过程中，常常会更改类名。而public型的类名在Java中要求必须与其文件名相同，因此，在更改类名时文件名也会更改，在这个问题上，SVN明显比VSS要合适。在VSS下，用户自行更改文件名后，VSS会认为原文件丢失，改名后的文件为新文件，而新文件则没有以前的版本记录。个人认为，在调取以前版本的文件时，将会遇到问题。
支撑平台：
VSS：Windows
SVN：Windows Linux Unix 以及所有可以运行Java虚拟机的系统
一点思考：
SVN充分发挥了开源的优势，在多环境下皆可以支持。而VSS在这方面则显得有些不足，但进行Windows开发时，VSS也是值得考虑的。
支持的开发工具（提供插件）：
VSS：Visual Studio系列，VSS Plugin for Eclipse
SVN：SVN for VS ， SVN for Eclipse
费用：
VSS：据说收费，但官网上没有发现售价，安装时也不需要破解。
SVN：开源免费，但须遵守Apache/BSD类型的协议。
一点思考：
对于小型项目、开源项目或个人实验而言，在版本控制上投入过多资金显然是不明智的。而在这种情况下，SVN提供的功能如果可以满足用户的需求的话，此问题上SVN显得更为合适。
只读保护：
VSS：在VSS中，迁出文件后，文件属性变为可写，迁入文件后，文件属性变为只读，用户如果不更改文件属性，则不能修改文件。VSS通过这种方式避免产成版本冲突。
SVN：对于SVN的Copy-Modify-Merge方式，由于允许产生冲突，所以无需使用只读保护。
实际应用时可能遇到的问题：
VSS：
在使用VSS时，不能长时间迁出，否则其他用户无法修改此文件，会影响项目进度。
但实际中可能遇到这种情况：
开发人员迁出文件，更改之后忘了迁入，之后开发人员出差，此时服务器中该文件将无法修改，对项目进度产生重大影响。
SVN：
因为SVN允许冲突，所以所有开发人员都需要解决冲突。可实际上，不是所有开发人员都能顺利、正确的解决冲突，一旦解决出错，错误并不会很容易被发现，可能会成为程序隐藏的Bug，给测试遗留问题。
笔者认为，采用SVN对程序设计团队的整体素质和沟通能力要求较高。
注：
VSS与SVN似乎都无法识别文件位置变化，希望在后续版本可以解决此问题。
各自适用范围：
VSS：
适合Windows平台开发，由于其收费，应该在资金充足的情况下考虑。独特的Lock-Modify-Unlock模式可以保证程序开发无冲突，这个特点也应在挑选版本控制工具时重点考虑。
因为修改时需要锁定，因此开发团队人员稳定，上班时间稳定的情况下更为适宜。
SVN：
适合多种平台，适合开源软件开发。Copy-Modify-Merge模式使用户可以将程序带回家开发，提升开发效率。但冲突会比VSS多，而所有人都可能需要解决冲突，这对整个团队人员的能力与沟通能力会有较高要求。 用的比较少了
页:
[1]
