八一八cvs vss svn和git比較
| 特征 | 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一些總結