特征 |
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), 等. 大多数都还在开 |
相关推荐
"版本控制工具比较:SVN、GIT、CVS及Mercurial" 版本控制是软件开发过程中的一个重要环节,用于跟踪和管理代码的变化。有多种版本控制工具可供选择,每种工具都有其特点和优缺。下面将对 SVN、GIT、CVS 及 ...
版本控制系统的历史中出现了多种类型,例如CVS和SVN都是早期的集中式版本控制系统,而Mercurial和Git则是较新的分布式版本控制系统。 CVS使用文件锁的机制来确保同一时间只有一个用户可以编辑一个文件,这避免了...
与集中式的版本控制系统(如CVS或SVN)不同,每个Mercurial工作副本都包含项目的所有历史记录,允许用户在没有网络连接的情况下进行本地操作。这极大地提升了开发效率,特别是在网络不稳定或者需要离线工作的环境中...
集中式版本控制工具如CVS、SVN和VSS,它们使用中央服务器来存储文件版本历史。与之相对的分布式版本控制工具,如Git、Mercurial、Bazaar和Darcs,每个开发者都拥有完整的项目副本,包括完整的版本历史记录。 Git是...
- **集中式(CVS,SVN)**:集中式版本控制系统如CVS和SVN通过将所有版本的数据集中存储在一台服务器上来解决多用户协作的问题。虽然这种方式提高了数据的集中管理能力,但一旦服务器出现问题,整个项目可能会受到...
- **SVN**(Subversion):改进版的集中式系统,相比CVS有更优秀的性能和稳定性。 - **Git**:Linus Torvalds为Linux内核开发的分布式版本控制系统,速度和效率高。 - **TFS**(Team Foundation Server):微软的...
集中式版本控制系统的代表有CVS和SVN,而Git和Mercurial(Hg)属于分布式版本控制系统。分布式版本控制系统的特点是简单易用、功能强大,且具有良好的操作系统的支持。 Git的官方网址是***,其中还推荐了两本学习...
- 例如:Subversion (SVN), CVS等。 - 在这类系统中,有一个中心服务器存放所有文件的唯一“主”副本。客户端通过与中心服务器进行交互来完成提交、更新等操作。 - **分布式版本控制系统 (Distributed Version ...
- **集中化的版本控制系统**:例如`CVS`、`Subversion`(SVN)等,这类系统将所有文件的版本库集中存放在中央服务器上,而各个开发者的工作副本仅仅包含单一时刻的文件快照。这种方式可以更好地支持多人协作,但存在...
- **SVN (Subversion)**:与CVS类似,但解决了CVS的一些问题,如更好的分支管理。 - **Mercurial**:另一个分布式系统,设计简洁,易于使用。 CVS在软件开发中的作用不可忽视,虽然现在有更多先进的版本控制系统,...
- **状态跟踪**:Git使用SHA-1散列算法计算文件的校验和,基于文件内容的变化来识别和跟踪文件状态。 #### 五、版本控制系统的优点 - **历史记录**:记录所有文件的修改历史,便于查看任意时间点的状态。 - **...
随后,集中化的版本控制系统如CVS和Subversion(SVN)出现,这些系统将整个项目历史记录保存在一个中央服务器上,导致了单点故障的问题,如果中央服务器出现故障,整个项目的历史记录就会丢失。 分布式版本控制系统...
此外,书中还提到了Subversion(SVN)和CVS等集中式版本控制系统,这些系统与分布式版本控制系统在工作方式上有很大的不同。在集中式版本控制系统中,所有开发者的改动都会提交到中央服务器上,这可能会带来潜在的单...