Subversion（SVN）被称为是CVS的下一代版本管理器，在版本管理的特性上有着许多独特的优势。我们建议，在团队今后的项目当中尽量使用SVN进行软件版本管理。此文档将简要的叙述如何使用SVN客户端和配置SVN服务器。
一、SVN（CVS）与VSS的区别
当前在轻量级版本管理方面应用较为广泛的版本管理软件主要有SVN（CVS）和VSS两类。其中SVN与CVS是Unix/Linux平台上广泛使用的版本管理软件，而VSS则是Microsoft推出的版本管理器。当然，他们之间的区别并不是简单的windows平台和*nix平台之间的区别。从本质上说，SVN与VSS对于版本的维护和修改采用了不同的模型。SVN采用的是“拷贝-修改-合并”模型，而VSS使用的是“锁定-修改-解锁”模型。对于曾经使用过VSS的同学来说，理解这两种模型的区别非常的重要，因为这对用户来说是两种完全不同的工作方式。建议大家阅读一下《使用Subversion进行版本控制》<[url]http://svn.red-bean.com/svnbook/trunk/www/index.zh.html[/url]> （幸运的是这本书居然有中文版，呵呵）当中的概念部分，再关注下面的内容。
关于SVN服务器所使用的模式，由于SVN支持如下的几种方式访问版本库，因此选择何种方式进行配置和使用就必须要在此说明清楚：
file:/// |
直接版本库访问（本地磁盘）。 |
http:// |
通过配置Subversion的Apache服务器的WebDAV协议。 |
https:// |
与 http://相似，但是包括SSL加密。 |
svn:// |
通过 svnserve服务自定义的协议。 |
svn+ssh:// |
与 svn://相似，但通过SSH封装 |
从服务器配置方面考虑，使用apache服务方式，即通过http://和https://方式进行版本库访问会加大服务器的负担，同时我们也不需要支持web浏览，因此可以排除上述两种。使用file:///方式是直接访问本地磁盘上的版本库，显然不符合我们的网络环境。于是我们可以选择的只有通过svn://或者svn+ssh://等svn私有协议方式进行。
对于使用svn://的方式，要求服务器端的svnserve服务进程始终处于监听状态，当用户连接到svn之后，svn服务器根据配置库下conf/svnserve.conf当中指定的用户密码文件对用户进行认证。值得注意的是，用户密码文件当中的用户名和密码是明文存放的，而且从服务器配置而言，是不允许用户自行修改密码的。这种方式对用户自身的隐私信息的保护并不利（因为很多用户喜欢在多个地方使用相同的密码）。
而另一种认证方式是svn+ssh://，即通过SSH登陆到服务器，由服务器而不是svn系统自身完成对用户的认证。在这种方式下，要求用户必须具备SSH到服务器的能力。在SSH到服务器之后，svn的客户端会发起一个svnserve的tunnel模式（隧道模式）的请求，而这个请求是以SSH登陆的用户名作为用户身份的，即在服务器上运行的svnserve进程的用户身份是SSH登陆的用户。在这种情况下，要顺利的完成对版本库的访问，就要求版本库所在的目录必须能够被发起svnserver进程的用户（也就是SSH登陆用户）读写。显然这样又会带来权限控制的问题，即用户具备了可以修改权限配置文件的能力使得权限控制成为摆设。幸运的是，svn+ssh://的方式还可以利用SSH的公钥、私钥对（也就是密钥对）进行认证。而且在将用户的公钥放置于服务器端之后，可以增加公钥当中的option字段，使得用户在使用密钥对认证时，调用svnserve进程，并且还可以在命令行当中指定svn当中的用户（即通过SSH认证但却是使用svn配置当中的用户）来进行版本库的操作。值得注意的是，在采用这种方式的情况下，如果用户具备SSH到服务器并且能够修改公钥当中option字段的能力时，svn是有安全隐患的。这意味着用户可以冒名任何一个svn系统当中的用户来对版本库进行访问，因为此时svn自身已经不进行身份验证，它仅通过tunnel模式在命令行参数上获取用户名。所以采用密钥对认证方式时，用户不应取得对服务器上自己发布的公钥进行修改的权力。由于SSH可以针对每一个的密钥对设置不同的访问命令，那么实际上可以将版本库放置到一个独立的用户/组（以下称为svnowner用户）名下，所有SSH到服务器的用户均使用这个独立且相同的用户名进行“登陆”。当然，用户不应获得这个独立的用户密码，否则就获得了取得shell并修改放置公钥的能力。所有的用户自己生成密钥对，由服务器的管理员将各个用户的公钥放置在svnowner用户的.ssh/authorized_keys当中，并设置其中的option字段，标注使用该公钥后对应的svn中对应用户。经过这样的配置，出现了如下的效果：
1、服务器上除了root和svnowner以外的所有用户均无法访问svn版本库；
2、所有真实的用户SSH到服务器所使用的用户名都是svnowner，但是由于不持有svnowner用户的密码，实际上无法登陆。如果为了安全，更可以将ssh服务器配置为不使用密码认证（即只使用密钥对认证）；
3、所有真实用户SSH到服务器通过认证的方式只能是利用自己手中的私钥与放置在服务器上自己的公钥匹配认证，认证完毕后ssh会自动执行公钥option字段当中的命令。管理员可以在放置公钥的时候在option字段当中用svnserve -t –tunnel-user=xxx的方式指定该公钥对应的svn用户名，此时通过svn+ssh://方式访问版本库的用户是利用系统svnowner身份执行svnserve访问版本库文件，但却在svn系统当中声明为xxx用户，受svn权限配置文件的约束。
4、用户访问版本库的唯一方法是通过密钥对，且管理员只掌握各用户的公钥。若用户遗失私钥，可以重新生成密钥对，再次将新的公钥发送给管理员，由管理员进行替换即可。
以下我将分使用SVN客户端和配置SVN服务器两个部分来进行描述。如果你仅仅作为一个普通用户，不担任团队的配置管理员或项目组的版本维护管理员，可以略过后面的部分。
