版本控制工具比较-CVS,SVN,GIT

标签：

首先介绍几个版本控制软件相互比较的重要依据，更详细的比较请参考文中链接：

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

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

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

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

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

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

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

对版本控制就有了一定的理解，同时也应该知道SVN与CVS是比较流行的两款SCM工具。那么到底这两款工具有什么区别呢？

　　1、版本编号方面

　　例如，我们的版本库为A，其中有文件a，b，c。

　　在SVN中，新版本的版本号不是针对某个特定文件的，而是针对整个库而言的。提交了5次和提交了6次，文件a有可能不同，也有可能相同，即 1.0版和1.1版可能相同。因为第6次提交有可能是因为文件b或c进行了修改。而在CVS中则相反，每次更新可能只对文件的版本号进行修改，即a文件的 1.0版和1.1版是肯定不同。

　　（在这里纠正一个概念，“文件a的第2版本”这个说法是错误的，应该是“文件a的第2次修改，即第二次Commit”）

　　SVN的全局性版本编号为SVN带来了诸多的优势：如对目录或文件执行拷贝，无论涉及多少文件，SVN不需要对单个文件依次执行拷贝命令，仅仅需要建立一个指向相应的全局版本号的一个指针即可。

　　2、目录的版本控制

　　CVS只能对文件进行版本控制，不能对目录进行版本控制，这就导致CVS失去了很多功能：

　　1）没有移动操作

　　CVS里没有移动（move）这个操作，当人为进行文件移动操作时，CVS只能注意到，一个文件在一个位置被删除了，而在一  个新位置创建了另外一个文件。由于它不会连接两个操作，因此也很容易使文件历史轨迹丢失。所以使用CVS时，每个文件的位置一定要谨慎的选择。

　　2）没有重命名操作

　　CVS里没有重命名（rename）这个操作，人为的对文件进行重命名会使得命名前后的文件失去历史联系，而记录历史本来是版本管理的主要目的。

　　3）没有拷贝操作

　　CVS中没有拷贝（copy）这个操作，人为的拷贝对CVS而言，只能看到新的文件的增加，而不能记录拷贝源文件和目标文件之间的联系。

　　而SVN从很大程度上避免了这些不足，SVN将目录作为一类特殊的文件来处理。当目录中的子目录/文件被删除、重命名、或新的子目录/文件被 创建时，目录的内容将发生改变。因此，SVN象记录普通文件的修改历史一样记录对目录的修改历史，当发生文件/目录的移动、重命名或拷贝操作时，SVN能 够准确记录操作前后的历史联系。同样，像对文件的不同历史版本进行比较一样，SVN支持对目录的不同历史版本的比较，清晰展现目录的变化历史。

　　3、原子性提交

　　CVS和SVN同样作为SCM版本控制管理工具，SVN的原子性提交可谓是技高一筹啊！

　　SVN提交文件，只有当全部文件修改都成功入库，该提交才变得有效。一旦中断，SVN将会自动执行“回滚”（rollback）操作。SVN 这种机制保证所有的修改要么全部入库生效，要么一个也不入库。由于SVN的原子性提交特性和全局版本编号方式，当提交成功完成时，一个唯一的、新的全局版 本编号产生，而提交时用户提供的日志信息与该新的版本编号关联，只进行一次存储（区别于CVS的按文件重复存储）。

我是一开始就用Mercurial, Git这类的系统。（现在已经百分百用Git了。）
用过Git之后才接触SVN，发现了一些非常大的差别。在这裡提出我个人一些主要理由為何弃SVN而用Git。

1。速度：
克 隆一份全新的目录，以同样拥有五个（才五个）分支来说，SVN是同时复製5个版本的文件，也就是说重复五次同样的动作。而Git只是获取文件的每个版本的 元素，然后只载入主要的分支（master）。在我的经验，克隆一个拥有将近一万个提交（commit），五个分支，每个分支有大约1500个文件的 SVN，耗了将近一个小时！而Git只用了区区的1分鐘！

2。版本库（repository）：
据我所知，SVN只能有一个指定中央版本库。当这个中央版本库有问题时，所有工作成员都一起瘫痪直到版本库维修完毕或者新的版本库设立完成。

而 Git可以有无限个版本库。或者，更正确的说法，每一个Git都是一个版本库，区别是它们是否拥有活跃目录（Git Working Tree）。如果主要版本库（例如：置於GitHub的版本库）发生了什麼事，工作成员仍然可以在自己的本地版本库（local repository）提交，等待主要版本库恢复即可。工作成员也可以提交到其他的版本库！

3。分支（Branch）
在SVN，分支是一个完整的目录。且这个目录拥有完整的实际文件。如果工作成员想要开啟新的分支，那将会影响“全世界”！每个人都会拥有和你一样的分支。如果你的分支是用来进行破坏工作（安检测试），那将会像传染病一样。

而 Git，每个工作成员可以任意在自己的本地版本库开啟无限个分支。举例：当我想尝试破坏自己的程序（安检测试），并且想保留这些被修改的文件供日后使用， 我可以开一个分支，做我喜欢的事。完全不需担心妨碍其他工作成员。只要我不合并及提交到主要版本库，没有一个工作成员会被影响。等到我不需要这个分支时， 我只要把它从我的本地版本库删除即可。无痛无痒。
Git的分支名是可以使用不同名字的。例如：我的本地分支名為testing，而在主要版本库的名字其实是master。
最值得一提，我可以在Git的任意一个提交点（commit point）开啟分支！（其中一个方法是使用gitk –all 可观察整个提交记录，然后在任意点开啟分支。）

4。提交（Commit）
在SVN，当你提交你的完成品时，它将直接记录到中央版本库。当你发现你的完成品存在严重问题时，你已经无法阻止事情的发生了。如果网路中断，你根本没办法提交！

而Git的提交完全属於本地版本库的活动。而你只需“推”（git push）到主要版本库即可。Git的“推”其实是在执行“同步”（Sync）。

5。重新设立起点（Rebase）
我没在SVN尝试过，不知道有没有这样的功能。

在 Git，如果你想把别人的最新提交设立為现在这个分支的起点，只要执行git rebase branch_name 即可。这个和合并（merge）不同点是，merge会依据修改的时间视為最新，而Rebase会要求你去解决双方都有修改过的地方的矛盾 （conflict）。

A - B - E
\- C - D
A - B - E
\ - C - D

6。系统档案
SVN会在每一个目录置放一个.svn。如果想移除这些.svn是很累的。
而Git会在目录起点拥有一个.git目录，以及.gitignore。

对我而言，管理一个Git 的版本库是很容易的事。

版本控制工具比较-CVS,SVN,GIT

标签：

原文地址：http://www.cnblogs.com/legend-song/p/4720704.html