首先介绍几个版本控制软件相互比较的重要依据：

a.版本库模型（Repository model）:描述了多个源码版本库副本间的关系，有客户端/服务器和分布式两种模式。在客户端/服务器模式下，每一用户通过客户端访问位于服务器的主版本库，每一客户机只需保存它所关注的文件副本，对当前工作副本（working copy）的更改只有在提交到服务器之后，其它用户才能看到对应文件的修改。而在分布式模式下，这些源码版本库副本间是对等的实体，用户的机器除了保存他们的工作副本外，还拥有本地版本库的历史信息。

b.并发模式（Concurrency model）:描述了当同时对同一工作副本/文件进行更改或编辑时，如何管理这种冲突以避免产生无意义的数据，有排它锁和合并模式。在排它锁模式下，只有发出请求并获得当前文件排它锁的用户才能对对该文件进行更改。而在合并模式下，用户可以随意编辑或更改文件，但可能随时会被通知存在冲突（两个或多个用户同时编辑同一文件），于是版本控制工具或用户需要合并更改以解决这种冲突。因此，几乎所有的分布式版本控制软件采用合并方式解决并发冲突。

c.历史模式（History model）：描述了如何在版本库中存贮文件的更改信息，有快照和改变集两种模式。在快照模式下，版本库会分别存储更改发生前后的工作副本；而在改变集模式下，版本库除了保存更改发生前的工作副本外，只保存更改发生后的改变信息。

d.变更范围（Scope of change）：描述了版本编号是针对单个文件还是整个目录树。

e.网络协议（Network protocols）：描述了多个版本库间进行同步时采用的网络协议。

f.原子提交性（Atomic commit）：描述了在提交更改时，能否保证所有更改要么全部提交或合并，要么不会发生任何改变。

g.部分克隆（Partial checkout/clone）：是否支持只拷贝版本库中特定的子目录。

名称	版本库模型	并发模式	历史模式	变更范围	网络协议	原子提交性	部分克隆
CVS	Client-server	Merge	Changeset	File	Pserver,ssh	No	Yes
SVN	Client-server	3-way merge, recursive merge, octopus merge	Changeset and Snapshot	Tree	custom (svn), custom (svn) over ssh, HTTP and SSL (usingWebDAV)	Yes	Yes
Git	Distributed	Merge or lock	Snapshot	Tree	custom, custom over ssh, rsync, HTTP/HTTPS, email, bundles	Yes	No

CVS(Concurrent Versions System)并发版本系统目前基本快要淘汰了；SVN和GIT的思想差别很大：公司里的集中式管理用SVN，开源开发git更合适。

SVN和GIT在用户管理和权限控制上都很强大而且方便。SVN更适合有稳定的集中服务器，开发人员数目不是非常多，如几十人的情形；GIT更适合大规模的分散开发，每个开发者大多数时间都是照看自己的小摊子的情形。

转自：http://www.cnblogs.com/sujz/archive/2011/05/12/2044379.html