《Git版本控制管理（第2版）》——1.3 先例

本節書摘來自異步社群《git版本控制管理（第2版）》一書中的第1章，第1.3節，作者：【美】jon loeliger , matthew mccullough著，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視

vcs的完整曆史已經超出了本書的讨論範圍。然而，有一些具有裡程碑、革新意義的系統值得一提。這些系統對git的開發或者有重要的鋪墊意義，或者有引導意義。（本節為可選章節，希望能夠記錄那些新特性出現的時間，以及在自由軟體社群變得流行的時間。）

源代碼控制系統（source code control system, sccs）是unix②上最初的幾個系統之一，由m. j. rochkind于20世紀70年代早期開發。[“the source code control system,” ieee transactions on software engineering 1(4) (1975): 364-370.]這是有證可查的可以運作在unix系統上的最早的vcs。

sccs提供的資料存儲中心稱為“版本庫”（repository），而這個基本概念一直沿用至今。sccs同樣提供了一個簡單的鎖模型來保證開發過程有序。如果一個開發人員需要運作或者測試一個程式，他需要将該程式解鎖并檢出。然而，如果他想修改某個檔案，他則需要鎖定并檢出（通過unix檔案系統執行的轉換）。當編輯完成以後，他又可以将檔案檢入到版本庫中并解鎖它。

修訂控制系統（revision control system，rcs）由walter f. tichy于20世紀80年代早期引入[“rcs: a system for version control,”software practice and experience 15(7) (1985): 637-654.]。rcs引入了雙向差異的概念，來提高檔案不同版本的存儲效率。

此外，cvs引入了一個關于“鎖”的新範式。而之前的系統需要開發人員在修改某個檔案之前先鎖定它，一個檔案同時隻允許一個開發人員進行修改，所有需要修改這個檔案的開發人員需要有序等候。cvs給予每個開發人員對于自己的私有版本寫的權限。是以，不同開發人員的改動可以自動合并，除非兩個開發人員嘗試修改同一行。如果出現修改同一行的情況，那這一行将會作為“沖突”被标記出來，由開發人員手動去解決。這個關于“鎖”的新規則使得多個開發人員可以并行地編寫代碼。

就像經常發生的那樣，對cvs短處和缺點的改進，促進了新vcs的誕生：subversion（svn）。svn于2001年問世，迅速風靡了開源社群。不像cvs，svn以原子方式送出改動部分，并且更好地支援分支。

bitkeeper和mercurial則徹底抛棄了上述所有解決方案。它們淘汰了中心版本庫的概念，取而代之的，資料的存儲是分布式的，每個開發人員都擁有自己可共享的版本庫副本。git則是從這種端點對端點（peer to peer）的模型繼承而來。

最後，mercurial和monotone首創了用散列指紋來唯一辨別檔案的内容，而檔案名隻是個“綽号”，旨在友善使用者操作，再沒有别的作用。git沿用了這個概念。從内部實作上來說，git的檔案辨別符基于檔案的内容，這是一個叫做“内容可尋址檔案存儲”（content addressable file store，cafs）的概念。這不是一個新概念。 據linus的說法③，git直接從monotone借用了這個概念。mercurial也同時實作了這個概念。