| 特征 |
CVS |
Git |
Mercurial |
Subversion |
| 是否原子提交 |
CVS: 没有. CVS提交不是原子的
|
Git: 是的. 提交都是原子的
|
Mercurial: 是的
|
Subversion: 提交都是原子的
|
| 文件和目录是否可以移动或重命名 |
CVS: 不是. 重命名不支持. 如果手动进行, 可能会损坏历史记录
|
Git: 支持重命名, 这是很实用的目的. git甚至能检测到重命名之后文件的改变. 尽管如此, 基于特殊的存储结构, 重命名不会被显示的记录, git能够推导出来(在实际使用中很容易做到)
|
Mercurial: 是的, 重命名是支持的 |
Subversion: 是的. 支持重命名
|
| 在移动或重命名之后智能合并 |
CVS: 不能. 重命名都不支持, 就不必说智能了
|
Git: 不支持. 细节在Git FAQ里: “Git有一个重命名的命令git mv, 但是这仅仅是为了便利. 效果和移掉某个文件, 增加另外一个文件没有任何区别”
|
Mercurial: 是的. 重命名之后智能合并是支持的. Mercurtial文档说:“如果我修改一个文件,而你重新命名了这个文件, 然后我们合并我们的变更, 那么我所做的修改就会被更新到根据旧文件名字而产生的新文件里(这可能就是你所期望的‘最简单的动作’, 但是不是所有版本控制系统都支持)
|
Subversion: 不支持. “svn help me“中提到“注意: 这个子命令相当于拷贝和删除.“并且可能有个bug
|
| 文件和目录拷贝 |
CVS: 不能. 拷贝不支持
|
Git: 不能. 拷贝不支持
|
Mercurtial: 是的. 支持拷贝
|
Subversion: 是的. 并且拷贝非常容易(O(1)). 包括产生分支 |
| 远程存储仓库的备份 |
CVS: 间接的. 可以使用John Polstra写的CVSup
|
Git: 是的. 是git的内部特征
|
Mercurial: 是的
|
Subversion: 间接的. 可以使用Chia-liang Kao的SVN::Mirror插件(好像是台湾人)或Shlomi Fish的SVN-Pusher工具
|
| 是否传递变更到父仓库 |
CVS: 不会
|
Git: 是的(Linux内核开发过程经常使用这个特征) |
Mercurtial: 是的 |
Subversion: 是的, 使用要么是Chia-Ling Kao的SVN::Mirror脚本或者Shlomi Fish的svn-push工具 |
| 仓库权限 |
CVS: 很有限. “pre-commit hook scripts“能够被用来实现各种权限控制系统 |
Git: 请看和Git一起附带的contrib/hooks/update-paranoid. 看和svnperms类似的path_rules的代码 |
Mercutial: 是的. 它能够锁住仓库, 子目录或者使用hooks后的文件 |
Subversion: 是的. 基于HTTP权限的WebDAV-based模块能够支持基于目录级的仓库 |
| 变更集 |
CVS: 不是. 变更是基于文件的 |
Git: 是的. 是支持的, 创建他们很容易 |
Mercurial: 是的. 变更集是支持的 |
Subversion: 部分支持. 对于一次提交会隐式创建一个变更集 |
| 跟踪线性的文件历史 |
CVS: 是的. cvs annotate |
Git: 是的.(git blame) |
Mercurial: 是的(hg annotate) |
Subversion: 是的(svn blame) |
| 能够只在仓库的单目录下作用 |
CVS: 是的 |
Git: 不是. 尽管如此, 提交多少能被限制, 请看“Repository Permissions” |
Mercurial: 能够基于某树的某个子集进行提交. 也有局部检出的能力 |
Subversion: 是的 |
| 跟踪未提交的变化 |
CVS: 是的. 通过cvs diff |
Git: 是的. 另外, 分支在git里非常智能, 在某些工作流里能够被当成是另外一个未提交代码的存储库. 请看“git stash“命令 |
Mercurial: 是的. 使用hg diff |
Subversion: 是的. 使用svn diff |
| 基于单个文件的提交信息 |
CVS: 不是. 提交信息是基于单次变化的 |
Git: 是的. 提交信息基于变更集 |
Mercurial: 不是 |
Subversion: 不是. 没有这个特征 |
| 文档 |
CVS: 非常棒. 有很多在线的tutorials和资源, 在线的书籍. 命令行客户端也支持一个在线的帮助系统 |
Git: 良好. 短的帮助比较简洁难懂. man页很有分量, 但容易误解. 有很多tutorial |
Mercurial: 很好. 有基于公司的书籍和wiki. 每个命令都集成了帮助 |
Subversion: 很好. 有一些在线的书籍和一些在线的tutorials和资源. 并且书籍是以docbook/xml写的所以很容易变换成其他格式. 命令行同样提供了在线的帮助系统 |
| 配置是否轻松 |
CVS: 好. 是个事实上的标准. 基于每个系统都有并且很容易配置 |
Git: 好. 在现有平台上二进制可用. 需要C编译器和Perl. 在windows上需要cygwin. 并有一些Unix特征 |
Mercurial: 非常好. 几乎所有平台都有二进制包. 从源码编译需要python2.3以上, 并且需要C编译器 |
Subversion: Subversion服务器需要安装在apache2模块里(如果有人希望HTTP作为底层协议的话)或使用它自身的服务器. 客户端需要Subversion特征的逻辑还有WebDAV库(针对HTTP). 安装组件很直接, 但是需要一些额外的工作(假定subversion在某些平台没有二进制包可用) |
| 命令集 |
CVS: 包含了3个经常用到的命令的简单的命令集(cvs commit, cvs update和cvs checkout)和其它一些 |
Git: 命令集很丰富, 并且和CVS不兼容 |
Mercurial: 尝试模仿CVS交互方式, 但是偏离了基于不同的设计的意图 |
Subversion: 类CVS的命令集, 能够很容易被CVS用户使用 |
| 网络支持 |
CVS: 好. cvs在不同的场合使用不同的协议. 协议能够通过ssh链接的加密隧道进行 |
Git: 非常棒. 能够使用本地的git协议, 但也能在rsync, ssh, HTTP和HTTPS上使用 |
Mercurial: 非常棒. 使用HTTP或ssh. 远程访问会非常安全, 在只读网络里不需要上锁 |
Subversion: 非常好. Subversion服务器支持WebDAV+DeltaV(基于HTTP或HTTPS)作为底层协议, 或者它自身的协议同样能在ssh链接通道里使用. |
| 可移植性 |
CVS: 好. 客户端能在UNIX, Windows和Mac OS上使用. 服务器端能在UNIX, 附有UNIX模拟层的Windows上使用 |
Git: 客户端运行在大多数的UNIX系统上, 但没有MS-Windows本地程序. 基于cygwin的系统看起来也能使用 |
Mercurial: 非常棒. 运行在基于所有能运行python的平台.仓库是兼容性的基于CPU结构和字节序的 |
Subversion: 非常好. 客户端和服务器端都能在UNIX, Windows和Mac OS X上运行 |
| web接口 |
CVS: 是的. CVSweb, ViewVC, Chora和wwCVS |
Git: 是的. Gitweb包含在发布包中 |
Mercurial: 是的. Web接口是内置组件 |
Subversion: 是的. ViewVC, SVN::Web, WebSVN, ViewSVN, mod_svn_view, Chora, Trac,SVN::RaWeb::Light,SVN Browser, Insurrection和perl_svn.另外, Subversion的apache服务也提供了一个基础的web接口 |
| 图形用户界面 |
CVS: 非常好. 有很多图形界面可以用: WinCVS, Cervisia(对于KDE), TortoiseCVS(Windows浏览器插件)
|
Git: Gitk包含在发行版中. Qqit和Git-gui工具也可使用 |
Mercurial: 通过hgit扩展查看历史; 检入扩展(hgct)使得提交很容易. 一些第三方的IDEs和GUI工具(如eric3, meld)有一些集成的Mercurial支持
|
Subversion: 非常好. 有很多GUIs可用: RapidSVN(跨平台), TortoiseSVN(Windows浏览器插件), Jsvn(java), 等. 大多数都还在开发中
|
综上所述：
1.CVS(Cocurrent Version System)并发版本系统
建立在RCS基础上,最流行的开放源代码版本控制系统
特点:
1),使用单一的主代码树,而不像RCS那样依赖多个目录.
2),最大优点在于多名开发人员可以同时对一个文件进行修改.允许合并.
这就"并发"开发.
2,SVN(SubVersion)
1)目录的版本控制
CVS 只能对文件进行版本控制，不能对目录进行版本控制.CVS 只能注意到，一个文件在一个位置被删除了，而在一个新位置创建了另外一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失
SVN可以
2)原子性提交
CVS 采用线性、串行的批量提交，即依次地，一个接一个地执行提交，每成功提交一个文件，该文件的一个新的版本即被记录到版本库中，提交时用户提供的日志信息被重复地存储到每一个被修改的文件的版本历史中。
CVS 串行批量提交模式的弊端在于 －当任何原因造成批量操作的中断时（典型原因包括：网络中断、客户端死机等），版本库往往处于一个不一致的状态：原本应该全部入库的文件只有一部分入库， 很有可能版本库中的最新版本不能顺利编译，更为严重的是，随着其他的用户执行cvs update 操作，该不一致性将迅速在开发团队中扩散，从而严重影响团队的开发效率，并存在质量隐患。另外，假如该批量提交的中断没有被及时发现，开发团队往往要花更 多的时间进行软件调试和排错。
Git 是用于 Linux 内核开发的版本控制工具。与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持，使源代码的发布和交流极其方便。 Git 的速度很快，这对于诸如 Linux kernel 这样的大项目来说自然很重要。 Git 最为出色的是它的合并跟踪（merge tracing）能力。
3,Git
Git 是用于 Linux 内核开发的版本控制工具。与常用的版本控制工具 CVS, Subversion 等不同，它采用了分布式版本库的方式，不必服务器端软件支持，使源代码的发布和交流极其方便。 Git 的速度很快，这对于诸如 Linux kernel 这样的大项目来说自然很重要。 Git 最为出色的是它的合并跟踪（merge tracing）能力。
git更加适合分布式开发项目。而svn（当然全称是subversion）则更适合于集中式大型开发项目。也有在git之上再使用一层svn的做法。
4.mercurial
Mercurial 是一种轻量级分布式版本控制系统，采用 Python 语言实现，易于学习和使用，扩展性强。其是基于 GNU General Public License (GPL) 授权的开源项目。
这是，我对svn，git，mecurial，git一些总结
