一直以来对于自己的项目都是使用CVS进行管理，听说Subversion很久了，但是都没有时间去尝试。想想时间都是省出来的，于是决定，一天学一点，不多，积累成河嘛。
Subversion和CVS相比，除了包含了CVS的全部特性之外，也加入了新的理念。
新理念
1、路径、改名、以及文件meta-data也可进入版本控制范围。
缺少这些特性是CVS被抱怨最多的方面之一，subversion不止对文件内容和文件存放位置加入控制，也对目录，拷贝，重命名操作加入版本控制。它也允许文件/目录的相关元数据meta-data和文件/目录本身一起被版本控制起来，并提供一种机制对文件的执行权限进行控制。
2、Commit动作真正成为原子级的操作了。
直到整个commit动作都成功前不会有任何部分的commit会生效。版本修订号只是预确认，而不是对文件预确认。(翻译不出来 -_-;)日志信息将绑定到修订信息，而不是象CVS那样冗余的存储下来。
3、提供Apache网络服务器选项，支持WebDAV/DeltaV协议。
Subversion可以使用基于http协议的WebDAV/DeltaV协议进行网络通讯，并由Apache服务器提供源码仓库方的网络浏览服务。这为Subversion提供了比CVS更好的协同工作能力，并提供了各式各样的自由的关键特性：授权，基于路径的授权，线性压缩，以及基本源码仓库浏览。
4、独立服务器选项
Subversion也能提供独立服务器选项，使用自定的协议（不是每个人都想运行Apache2.x）独立服务器可以作为系统的inetd服务运行，并提供基本的授权。它也能使用ssh进行加密。
5、建立分支和标签操作成为不耗时的操作。
这些动作没理由耗时，所以我们不再让它们耗时。
6、分支与标签的实现都是基于底层的拷贝操作，一个拷贝占用一块固定大小的空间。任何拷贝都可以作为一份标签；假如你开始对某个版本的拷贝进行commit动作，那它也就成为一个分支。(这与CVS的"分支节点做标签"方式不同)
7、天然的client/server结构，层次化库设计。
Subversion从设计之初即采用client/server机构；因此避免了困扰CVS了许久的一些维护性难题。
代码被构建为一组带有详细接口说明的模块，用以方便的由其他应用程序进行调用。
8、Client/server协议向双方发送对比差异。
网络协议利用宽带有效地发送对比差异给客户端和服务器端双方。( CVS只是 server->client,?没有client->server )
9、资源消耗与数据改变的大小成正比，而不是与数据本身大小成正比一般来说，一项Subversion操作所需时间与操作最终变化的大小成正比。而不是与操作所触及的整个项目的大小成正比，这是Subversion源代码仓库模型的一个特性。
10、有效的处理二进制文件
Subversion对于二进制文件和文本文件的处理同样有效，因为subversion使用一种二进制差异比较算法来增量存储那些连续的修订本。
11、易于语法分析的输出。
所有Subversion命令行客户端的输出都是仔细设计的，可轻松为人所理解，也适于程序自动解析。可进行脚本语言处理将是下一步优先考虑的特性。
好了，开始使用吧。
Subversion到目前的安装已经非常简单了。到Subversion网站下载Windows下的安装文件，简单的步骤就可以完成安装，而且安装程序已经自动注册Path，直接在命令行模式就可以使用了。
首先初始化Repository，输入命令:
svnadmin create D:"TestRepository"
然后，把现有的项目的目录结构以及文件导入到Repository中：
svn import D:"Projects"Project1 file:///D:"TestRepository"Project1 -m “初始化“
用启动服务
svnserve -d -r D:"TestRepository"
客户端Checkout
svn checkout svn://主机名/Project1?? (即获取Project1的项目)
以上都是很简单的命令。而且上面只用到了一种服务模式，Apache的还在尝试中。
目前只用到了Subversion的基本功能，就已经感觉不错了，觉得入门很轻松，帮助文档也比CVS要好的多。
Subversion也有图形的客户端，可以在 TortoiseSVN 找到。
Subversion也VS.Net的插件，可以在AnkhSVN 找到。
TortoiseSVN相信不错，因为以前用过它的另一个For CVS的工具，可以和浏览器结合在一起，非常方便和美观。
服务
Subversion具有两种服务模式，一个是作为Apache的模块，另一个是自定义协议的Subserve服务。作为Apache的模块，客户端可以通过WebDAV/DeltaV协议访问Repository，而使用Subserve则使用
Subversion的自定义协议。
下表是两种服务模式的比较：
|
功能
|
Apache + mod_dav_sub
|
Svnserve
|
|
验证方式
|
基于HTTPS的X.509、LDAP、NTLM或其他Apache支持的验证
|
CRAM-MD5或者SSH
|
|
用户帐户管理
|
私有的用户文件
|
私有的用户文件或已有的系统帐户
|
|
授权管理
|
blanket read/write access或单一目录的访问控制
|
blanket read/write access
|
|
加密
|
可选的SSL
|
可选的SSH隧道
|
|
交互性
|
可通过支持WebDAV的客户端访问
|
无交互性
|
|
Web访问
|
有限的内置支持，或通过第三方的工具，例如ViewCVS
|
通过第三方的支持，如ViewCVS
|
|
速度
|
稍慢
|
稍快
|
|
初始安装
|
稍复杂
|
相当简单
|
启动svnserve服务
svnserve 是一个轻量级的服务， 使用自定义的协议通过TCP/IP与客户端通讯。
客户端通过由 svn:// 或者 svn+ssh:// 开始的URL访问svnserve服务器。
启动服务器
端口监控（inetd）模式
如果你打算用端口监控来启动处理客户的访问请求的进程，你可以通过传入参数-i来启动：
svnserve -i
当使用-i参数启动服务的时候，svnserve通过stdin和stdout用自定义协议和客户端
通讯。同时服务侦听3690端口。
独立端口监控进程
使用参数-d启动服务作为一个独立的端口监控进程。
svnserve -d
当运行svnserve在独立端口监控模式时，你可以使用--listen-port=和--listen-host=参数来自定义需要的端口和主机名称。当前模式默认的端口是3690。
当然，也有第三种方法启动svnserve，也就是使用“隧道模式”，使用-t参数启动服务。这个模式要求远程服务程序，如RSH或SSH，已经成功验证用户，并且使用已经校验的用户启动一个属于该用户的svnserve进程。当使用该模式提供服务时，要确认启动的用户帐户具备对Repository的读/写权限。
设置项目目录
当svnserve开始运行时，它将会暴露所有的Repository到网络上。不过，当客户端需要获取一个Repository的内容时，需要指定Reopsitory的绝对路径。例如：一个Repository放在文件路径
C:/Project Repository/Project1
那么当客户端访问时，需要指定绝对路径：
svn://host/C:/Project Repository/Project1
所以，为了增加保密性，你可以使用参数-r指定需要暴露的Repository的路径，当用户访问时，只需指定Repository的名称即可。例如上面的Repository，当启动服务时，使用如下的方法：
svn -d -r C:/Project Repository
那么当客户端访问时，则使用
svn://host/Project1
就可以获取数据了。
内置的验证和授权
当客户端连接到一个svnserve进程时，下面的流程就会触发：
1、客户选择一个指定的Repository；
2、服务处理Repository的配置文件 conf/svnserve.conf文件，并且开始执行在其中定义的所有验证和授权策略；
3、依赖与情形和授权策略：
a)客户端也许允许匿名访问而不需要验证，或者
b)客户但也许需要在任何时候被要求验证，或者
c)假如处于"隧道模式"中，客户端将声明自己已经可以被外部验证。
很显然，如上所说，用户文件是一个名为svnserve.conf的，放在conf目录下的文件。
现在我们来看看如何配置这个文件：
这个配置文件放置在Repository的目录中的conf目录下，它有两个节点：
[general]
[users]
其中，[general]的配置信息有：
anon-access = read
auth-access = write
其中表示对于验证有效的以及没通过验证的用户可以做什么事情。分别有read, write和none
[users]的标签的配置内容有：
USERNAME = PASSWORD
password-db = passwd
realm = My First Repository
其中表示，用户名对应的密码是什么，或者指定一个存储用户名和密码的文件的相对或绝对路径以及指定了Repository的验证领域。如果两个Repository有相同的验证领域，那么它们应该有相同的密码数据库，反之亦然。默认的领域就是指向当前的Repository的路径，与服务器的Repository的根目录相关。
几个版本控制工具的比较:
cvs是开源项目，其功能比vss强大很多，可以支持版本合并，多个分支。而vss是比较简单和易用的配置管理工具。在这两个工具的选择上还是要看是项目决定，一般10个人以下的团队vss可能更方便一些~~~
cvs是并行版本管理器，开源，可以多人同时修改一个文件，当出现冲突的时候自动合入或者提示；
vss是微软visual studio中附带的版本管理器，只能在windows局域网环境下使用。使用一个文件同时只能由一个人来修改的方法来避免冲突。最大的优点是易学，并且跟visual studio可以无缝集成。
cvs,vss 都是版本控制的软件工具，可以把源代码或者其他文件的每一次修改的内容都保存起来，算是可以看以前版本的代码。
vss 基于文件共享的机制，易用性好，安全性不太好。vss 对于同时增加删除多个目录的支持很好。分支合并管理也很容易使用，打标签功能不太好用。vss 基于文件锁机制，同一时刻，只能有一个人修改同一个文件。
cvs 基于 c/s 结构，也有工具可以让它 b/s 运行，不过 b/s 速度慢，使用者不多。cvs 安全控制比较好，对于同时增加多个目录的支持不太好。cvs 中删除目录很难。cvs可以同一时刻多人修改统一文件然后合并，不过只支持文本文件；对于 office 或者其他格式的文档，多个人同时修改同一个文件很难合并，浪费大家时间。我在网上搜索让cvs支持锁机制，只有少数文章提到在 server 端用 script 控制，语焉不详。
总体来说，cvs 功能比vss强。