Git 前時(shí)代：使用 CVS 進(jìn)行版本控制（cvs和git）
編譯自： https://twobithistory.org/2018/07/07/CVS.html
作者： Two-bit History
譯者： runningwater
GitHub 網(wǎng)站發(fā)布于 2008 年。如果你的軟件工程師職業(yè)生涯跟我一樣，也是晚于此時(shí)間的話，Git 可能是你用過的唯一版本控制軟件。雖然其陡峭的學(xué)習(xí)曲線和不直觀地用戶界面時(shí)常會(huì)遭人抱怨，但不可否認(rèn)的是，Git 已經(jīng)成為學(xué)習(xí)版本控制的每個(gè)人的選擇。Stack Overflow 2015 年進(jìn)行的開發(fā)者調(diào)查顯示，69.3% 的被調(diào)查者在使用 Git，幾乎是排名第二的 Subversion 版本控制系統(tǒng)使用者數(shù)量的兩倍。 1 2015 年之后，也許是因?yàn)?Git 太受歡迎了，大家對此話題不再感興趣，所以 Stack Overflow 停止了關(guān)于開發(fā)人員使用的版本控制系統(tǒng)的問卷調(diào)查。
GitHub 的發(fā)布時(shí)間距離 Git 自身發(fā)布時(shí)間很近。2005 年，Linus Torvalds 發(fā)布了 Git 的首個(gè)版本。現(xiàn)在的年經(jīng)一代開發(fā)者可能很難想象“版本控制軟件”一詞所代表的世界并不僅僅只有 Git，雖然這樣的世界誕生的時(shí)間并不長。除了 Git 外，還有很多可供選擇。那時(shí)，開源開發(fā)者較喜歡 Subversion，企業(yè)和視頻游戲公司使用 Perforce （到如今有些仍在用），而 Linux 內(nèi)核項(xiàng)目依賴于名為 BitKeeper 的版本控制系統(tǒng)。
其中一些系統(tǒng)，特別是 BitKeeper，會(huì)讓年經(jīng)一代的 Git 用戶感覺很熟悉，上手也很快，但大多數(shù)相差很大。除了 BitKeeper，Git 之前的版本控制系統(tǒng)都是以不同的架構(gòu)模型為基礎(chǔ)運(yùn)行的?！?Version Control By Example 》一書的作者 Eric Sink 在他的書中對版本控制進(jìn)行了分類，按其說法，Git 屬于第三代版本控制系統(tǒng)，而大多數(shù) Git 的前身，即流行于二十世紀(jì)九零年代和二十一世紀(jì)早期的系統(tǒng)，都屬于第二代版本控制系統(tǒng)。 2 第三代版本控制系統(tǒng)是分布式的，第二代是集中式。你們以前大概都聽過 Git 被描述為一款“分布式”版本控制系統(tǒng)。我一直都不明白分布式/集中式之間的區(qū)別，隨后自己親自安裝了一款第二代的集中式版本控件系統(tǒng)，并做了相關(guān)實(shí)驗(yàn)，至少明白了一些。
我安裝的版本系統(tǒng)是 cvs。CVS，即 “ 并發(fā)版本系統(tǒng)(Concurrent Versions System)” 的縮寫，是最初的第二代版本控制系統(tǒng)。大約十年間，它是最為流行的版本控制系統(tǒng)，直到 2000 年被 Subversion 所取代。即便如此，Subversion 被認(rèn)為是 “更好的 CVS”，這更進(jìn)一步突出了 CVS 在二十世紀(jì)九零年代的主導(dǎo)地位。
CVS 最早是由一位名叫 Dick Grune 的荷蘭科學(xué)家在 1986 年開發(fā)的，當(dāng)時(shí)有一個(gè)編譯器項(xiàng)目，他正在尋找一種能與其學(xué)生合作的方法。 3 CVS 最初僅僅只是一個(gè)包裝了 RCS（ 修訂控制系統(tǒng)(Revision Control System)) 的 Shell 腳本集合，Grune 想改進(jìn)這個(gè)第一代的版本控制系統(tǒng)。 RCS 是按悲觀鎖模式工作的，這意味著兩個(gè)程序員不可以同時(shí)處理同一個(gè)文件。需要編輯一個(gè)文件話，首先得向 RCS 系統(tǒng)請求一個(gè)排它鎖，鎖定此文件直到完成編輯，如果你想編輯的文件有人正在編輯，你就必須等待。CVS 在 RCS 基礎(chǔ)上改進(jìn)，并把悲觀鎖模型替換成樂觀鎖模型，迎來了第二代版本控制系統(tǒng)的時(shí)代?，F(xiàn)在，程序員可以同時(shí)編輯同一個(gè)文件、合并編輯部分，隨后解決合并沖突問題。（后來接管 CVS 項(xiàng)目的工程師 Brian Berliner 于 1990 年撰寫了一篇非常易讀的關(guān)于 CVS 創(chuàng)新的 論文 。）
從這個(gè)意義上來講，CVS 與 Git 并無差異，因?yàn)?Git 也是運(yùn)行于樂觀鎖模式的，但也僅僅只有此點(diǎn)相似。實(shí)際上，Linus Torvalds 開發(fā) Git 時(shí)，他的一個(gè)指導(dǎo)原則是 WWCVSND，即 “ CVS 不能做的(What Would CVS Not Do)”。每當(dāng)他做決策時(shí)，他都會(huì)力爭選擇那些在 CVS 設(shè)計(jì)里沒有使用的功能選項(xiàng)。 4 所以即使 CVS 要早于 Git 十多年，但它對 Git 的影響是反面的。
我非常喜歡折騰 CVS。我認(rèn)為要弄明白為什么 Git 的分布式特性是對以前的版本控制系統(tǒng)的極大改善的話，除了折騰 CVS 外，沒有更好的辦法。因此，我邀請你跟我一起來一段激動(dòng)人心的旅程，并在接下來的十分鐘內(nèi)了解下這個(gè)近十年來無人使用的軟件。（可以看看文末“修正”部分）
CVS 入門
CVS 的安裝教程可以在其 項(xiàng)目主頁 上找到。MacOS 系統(tǒng)的話，可以使用 Homebrew 安裝。
由于 CVS 是集中式的，所以它有客戶端和服務(wù)端之區(qū)分，這種模式 Git 是沒有的。兩端分別有不同的可執(zhí)行文件，其區(qū)別不太明顯。但要開始使用 CVS 的話，即使只在你的本地機(jī)器上使用，也必須設(shè)置 CVS 的服務(wù)后端。
CVS 的后端，即所有代碼的中央存儲(chǔ)區(qū)，被叫做 存儲(chǔ)庫( repository)。在 Git 中每一個(gè)項(xiàng)目都有一個(gè)存儲(chǔ)庫，而 CVS 中一個(gè)存儲(chǔ)庫就包含所有的項(xiàng)目。盡管有辦法保證一次只能訪問一個(gè)項(xiàng)目，但一個(gè)中央存儲(chǔ)庫包含所有東西是改變不了的。
要在本地創(chuàng)建存儲(chǔ)庫的話，請運(yùn)行 init 命令。你可以像如下所示在家目錄創(chuàng)建，也可以在你本地的任何地方創(chuàng)建。
$ cvs -d ~/sandbox init
CVS 允許你將選項(xiàng)傳遞給 cvs 命令本身或 init 子命令。出現(xiàn)在 cvs 命令之后的選項(xiàng)默認(rèn)是全局的，而出現(xiàn)在子命令之后的是子命令特有選項(xiàng)。上面所示例子中，-d 標(biāo)志是全局選項(xiàng)。在這兒是告訴 CVS 我們想要?jiǎng)?chuàng)建存儲(chǔ)庫路徑在哪里，但一般 -d 標(biāo)志指的是我們想要使用的且已經(jīng)存在的存儲(chǔ)庫位置。一直使用 -d 標(biāo)志很單調(diào)乏味，所以可以設(shè)置 CVSROOT 環(huán)境變量來代替。
因?yàn)槲覀冎皇窃诒镜夭僮?，所以僅僅使用 -d 參考來傳遞路徑就可以，但也可以包含個(gè)主機(jī)名。
此命令在你的家目錄創(chuàng)建了一個(gè)名叫 sandbox 的目錄。 如果你列出 sandbox 內(nèi)容，會(huì)發(fā)現(xiàn)下面包含有名為 CVSROOT 的目錄。請不要把此目錄與我們的環(huán)境變量混淆，它保存存儲(chǔ)庫的管理文件。
恭喜！ 你剛剛創(chuàng)建了第一個(gè) CVS 存儲(chǔ)庫。
檢入代碼
假設(shè)你決定留存下自己喜歡的顏色清單。因?yàn)槟闶且粋€(gè)有藝術(shù)傾向但很健忘的人，所以你鍵入顏色列表清單，并保存到一個(gè)叫 favorites.txt 的文件中：
blue
orange
green
definitely not yellow
我們也假設(shè)你把文件保存到一個(gè)叫 colors 的目錄中?，F(xiàn)在你想要把喜歡的顏色列表清單置于版本控制之下，因?yàn)閺默F(xiàn)在起的五十年間你會(huì)回顧下，隨著時(shí)間的推移自己的品味怎么變化，這件事很有意思。
為此，你必須將你的目錄導(dǎo)入為新的 CVS 項(xiàng)目。可以使用 import 命令：
$ cvs -d ~/sandbox import -m \”\” colors colors initial
N colors/favorites.txt
No conflicts created by this import
這里我們再次使用 -d 標(biāo)志來指定存儲(chǔ)庫的位置，其余的參數(shù)是傳輸給 import 子命令的。必須要提供一條消息，但這兒沒必要，所以留空。下一個(gè)參數(shù) colors，指定了存儲(chǔ)庫中新目錄的名字，這兒給的名字跟檢入的目錄名稱一致。最后的兩個(gè)參數(shù)分別指定了 “vendor” 標(biāo)簽和 “release” 標(biāo)簽。我們稍后就會(huì)談?wù)摌?biāo)簽。
我們剛將 colors 項(xiàng)目拉入 CVS 存儲(chǔ)庫。將代碼引入 CVS 有很多種不同的方法，但這是 《 Pragmatic Version Control Using CVS 》 一書所推薦方法，這是一本關(guān)于 CVS 的程序員實(shí)用指導(dǎo)書籍。使用這種方法有點(diǎn)尷尬的就是你得重新 檢出(check out)工作項(xiàng)目，即使已經(jīng)存在有 colors 此項(xiàng)目了。不要使用該目錄，首先刪除它，然后從 CVS 中檢出剛才的版本，如下示：
$ cvs -d ~/sandbox co colors
cvs checkout: Updating colors
U colors/favorites.txt
這個(gè)過程會(huì)創(chuàng)建一個(gè)新的目錄，也叫做 colors。此目錄里會(huì)發(fā)現(xiàn)你的源文件 favorites.txt，還有一個(gè)叫 CVS 的目錄。這個(gè) CVS 目錄基本上與每個(gè) Git 存儲(chǔ)庫的 .git 目錄等價(jià)。
做出改動(dòng)
準(zhǔn)備旅行。
和 Git 一樣，CVS 也有 status 命令：
$ cvs status
cvs status: Examining .
===================================================================
File: favorites.txt Status: Up-to-date
Working revision: 1.1.1.1 2018-07-06 19:27:54 -0400
Repository revision: 1.1.1.1 /Users/sinclairtarget/sandbox/colors/favorites.txt,v
Commit Identifier: fD7GYxt035GNg8JA
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
到這兒事情開始陌生起來了。CVS 沒有提交對象這一概念。如上示，有一個(gè)叫 “ 提交標(biāo)識(shí)符(Commit Identifier)” 的東西，但這可能是一個(gè)較新版本的標(biāo)識(shí)，在 2003 年出版的《Pragmatic Version Control Using CVS》一書中并沒有提到 “提交標(biāo)識(shí)符” 這個(gè)概念。 （CVS 的最新版本于 2008 年發(fā)布的。 5 ）
在 Git 中，我們所談?wù)撃澄募姹酒鋵?shí)是在談?wù)撊?commit 45de392 相關(guān)的東西，而 CVS 中文件是獨(dú)立版本化的。文件的第一個(gè)版本為 1.1 版本，下一個(gè)是 1.2 版本，依此類推。涉及分支時(shí)，會(huì)在后面添加擴(kuò)展數(shù)字。因此你會(huì)看到如上所示的 1.1.1.1 的內(nèi)容，這就是示例的版本號(hào)，即使我們沒有創(chuàng)建分支，似乎默認(rèn)的會(huì)給加上。
一個(gè)項(xiàng)目中會(huì)有很多的文件和很多次的提交，如果你運(yùn)行 cvs log 命令（等同于 git log），會(huì)看到每個(gè)文件提交歷史信息。同一個(gè)項(xiàng)目中，有可能一個(gè)文件處于 1.2 版本，一個(gè)文件處于 1.14 版本。
繼續(xù)，我們對 1.1 版本的 favorites.txt 文件做些修改（LCTT 譯注：原文此處示例有誤）：
blue
orange
green
cyan
definitely not yellow
修改完成，就可以運(yùn)行 cvs diff 來看看 CVS 發(fā)生了什么：
$ cvs diff
cvs diff: Diffing .
Index: favorites.txt
===================================================================
RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,v
retrieving revision 1.1.1.1
diff -r1.1.1.1 favorites.txt
3a4
> cyan
CVS 識(shí)別出我們我在文件中添加了一個(gè)包含顏色 “cyan” 的新行。（實(shí)際上，它說我們已經(jīng)對 “RCS” 文件進(jìn)行了更改；你可以看到，CVS 底層使用的還是 RCS。） 此差異指的是當(dāng)前工作目錄中的 favorites.txt 副本與存儲(chǔ)庫中 1.1.1.1 版本的文件之間的差異。
為了更新存儲(chǔ)庫中的版本，我們必須提交更改。Git 中，這個(gè)操作要好幾個(gè)步驟。首先，暫存此修改，使其在索引中出現(xiàn)，然后提交此修改，最后，為了使此修改讓其他人可見，我們必須把此提交推送到源存儲(chǔ)庫中。
而 CVS 中，只需要運(yùn)行 cvs commit 命令就搞定一切。CVS 會(huì)匯集它所找到的變化，然后把它們放到存儲(chǔ)庫中：
$ cvs commit -m \”Add cyan to favorites.\”
cvs commit: Examining .
/Users/sinclairtarget/sandbox/colors/favorites.txt,v <– favorites.txt
new revision: 1.2; previous revision: 1.1
我已經(jīng)習(xí)慣了 Git，所以這種操作會(huì)讓我感到十分恐懼。因?yàn)闆]有變更暫存區(qū)的機(jī)制，工作目錄下任何你動(dòng)過的東西都會(huì)一股腦給提交到公共存儲(chǔ)庫中。你有過因?yàn)椴凰较吕镏貙懥四硞€(gè)同事不佳的函數(shù)實(shí)現(xiàn)，但僅僅只是自我宣泄一下并不想讓他知道的時(shí)候嗎？如果不小心提交上去了，就太糟糕了，他會(huì)認(rèn)為你是個(gè)混蛋。在推送它們之前，你也不能對提交進(jìn)行編輯，因?yàn)樘峤痪褪峭扑汀＿€是你愿意花費(fèi) 40 分鐘的時(shí)間來反復(fù)運(yùn)行 git rebase -i 命令，以使得本地提交歷史記錄跟數(shù)學(xué)證明一樣清晰嚴(yán)謹(jǐn)？很遺憾，CVS 里不支持，結(jié)果就是，大家都會(huì)看到你沒有先寫測試用例。
不過，到現(xiàn)在我終于理解了為什么那么多人都覺得 Git 沒必要搞那么復(fù)雜。對那些早已經(jīng)習(xí)慣直接 cvs commit 的人來說，進(jìn)行暫存變更和推送變更操作確實(shí)是毫無意義的差事。
人們常談?wù)?Git 是一個(gè) “分布式” 系統(tǒng)，其中分布式與非分布式的主要區(qū)別為：在 CVS 中，無法進(jìn)行本地提交。提交操作就是向中央存儲(chǔ)庫提交代碼，所以沒有網(wǎng)絡(luò)連接，就無法執(zhí)行操作，你本地的那些只是你的工作目錄而已；在 Git 中，會(huì)有一個(gè)完完全全的本地存儲(chǔ)庫，所以即使斷網(wǎng)了也可以無間斷執(zhí)行提交操作。你還可以編輯那些提交、回退、分支，并選擇你所要的東西，沒有任何人會(huì)知道他們必須知道的之外的東西。
因?yàn)樘峤皇莻€(gè)大事，所以 CVS 用戶很少做提交。提交會(huì)包含很多的內(nèi)容修改，就像如今我們能在一個(gè)含有十次提交的拉取請求中看到的一樣多。特別是在提交觸發(fā)了 CI 構(gòu)建和自動(dòng)測試程序時(shí)如此。
現(xiàn)在我們運(yùn)行 cvs status，會(huì)看到產(chǎn)生了文件的新版本：
$ cvs status
cvs status: Examining .
===================================================================
File: favorites.txt Status: Up-to-date
Working revision: 1.2 2018-07-06 21:18:59 -0400
Repository revision: 1.2 /Users/sinclairtarget/sandbox/colors/favorites.txt,v
Commit Identifier: pQx5ooyNk90wW8JA
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
合并
如上所述，在 CVS 中，你可以同時(shí)編輯其他人正在編輯的文件。這是 CVS 對 RCS 的重大改進(jìn)。當(dāng)需要將更改的部分重新組合在一起時(shí)會(huì)發(fā)生什么？
假設(shè)你邀請了一些朋友來將他們喜歡的顏色添加到你的列表中。在他們添加的時(shí)候，你確定了不再喜歡綠色，然后把它從列表中刪除。
當(dāng)你提交更新的時(shí)候，會(huì)發(fā)現(xiàn) CVS 報(bào)出了個(gè)問題：
$ cvs commit -m \”Remove green\”
cvs commit: Examining .
cvs commit: Up-to-date check failed for `favorites.txt\’
cvs [commit aborted]: correct above errors first!
這看起來像是朋友們首先提交了他們的變化。所以你的 favorites.txt 文件版本沒有更新到存儲(chǔ)庫中的最新版本。此時(shí)運(yùn)行 cvs status 就可以看到，本地的 favorites.txt 文件副本有一些本地變更且是 1.2 版本的，而存儲(chǔ)庫上的版本號(hào)是 1.3，如下示：
$ cvs status
cvs status: Examining .
===================================================================
File: favorites.txt Status: Needs Merge
Working revision: 1.2 2018-07-07 10:42:43 -0400
Repository revision: 1.3 /Users/sinclairtarget/sandbox/colors/favorites.txt,v
Commit Identifier: 2oZ6n0G13bDaldJA
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: (none)
你可以運(yùn)行 cvs diff 來了解 1.2 版本與 1.3 版本的確切差異：
$ cvs diff -r HEAD favorites.txt
Index: favorites.txt
===================================================================
RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,v
retrieving revision 1.3
diff -r1.3 favorites.txt
3d2
< green
7,10d5
<
< pink
< hot pink
< bubblegum pink
看來我們的朋友是真的喜歡粉紅色，但好在他們編輯的是此文件的不同部分，所以很容易地合并此修改。跟 git pull 類似，只要運(yùn)行 cvs update 命令，CVS 就可以為我們做合并操作，如下示：
$ cvs update
cvs update: Updating .
RCS file: /Users/sinclairtarget/sandbox/colors/favorites.txt,v
retrieving revision 1.2
retrieving revision 1.3
Merging differences between 1.2 and 1.3 into favorites.txt
M favorites.txt
此時(shí)查看 favorites.txt 文件內(nèi)容的話，你會(huì)發(fā)現(xiàn)你的朋友對文件所做的更改已經(jīng)包含進(jìn)去了，你的修改也在里面?，F(xiàn)在你可以自由的提交文件了，如下示：
$ cvs commit
cvs commit: Examining .
/Users/sinclairtarget/sandbox/colors/favorites.txt,v <– favorites.txt
new revision: 1.4; previous revision: 1.3
最終的結(jié)果就跟在 Git 中運(yùn)行 git pull –rebase 一樣。你的修改是添加在你朋友的修改之后的，所以沒有 “合并提交” 這操作。
某些時(shí)候，對同一文件的修改可能導(dǎo)致沖突。例如，如果你的朋友把 “green” 修改成 “olive”，同時(shí)你完全刪除 “green”，就會(huì)出現(xiàn)沖突。CVS 早期的時(shí)候，正是這種情況導(dǎo)致人們擔(dān)心 CVS 不安全，而 RCS 的悲觀鎖機(jī)制可以確保此情況永不會(huì)發(fā)生。但 CVS 提供了一個(gè)安全保障機(jī)制，可以確保不會(huì)自動(dòng)的覆蓋任何人的修改。因此，當(dāng)運(yùn)行 cvs update 的時(shí)候，你必須告訴 CVS 想要保留哪些修改才能繼續(xù)下一步操作。CVS 會(huì)標(biāo)記文件的所有變更，這跟 Git 檢測到合并沖突時(shí)所做的方式一樣，然后，你必須手工編輯文件，選擇需要保留的變更進(jìn)行合并。
這兒需要注意的有趣事情就是在進(jìn)行提交之前必須修復(fù)并合并沖突。這是 CVS 集中式特性的另一個(gè)結(jié)果。而在 Git 里，在推送本地的提交內(nèi)容之前，你都不用擔(dān)心合并沖突問題。
標(biāo)記與分支
由于 CVS 沒有易于尋址的提交對象，因此對變更集合進(jìn)行分組的唯一方法就是對于特定的工作目錄狀態(tài)打個(gè)標(biāo)記。
創(chuàng)建一個(gè)標(biāo)記是很容易的：
$ cvs tag VERSION_1_0
cvs tag: Tagging .
T favorites.txt
稍后，運(yùn)行 cvs update 命令并把標(biāo)簽傳輸給 -r 標(biāo)志就可以把文件恢復(fù)到此狀態(tài)，如下示：
$ cvs update -r VERSION_1_0
cvs update: Updating .
U favorites.txt
因?yàn)槟阈枰粋€(gè)標(biāo)記來回退到早期的工作目錄狀態(tài)，所以 CVS 鼓勵(lì)創(chuàng)建大量的搶先標(biāo)記。例如，在重大的重構(gòu)之前，你可以創(chuàng)建一個(gè) BEFORE_REFACTOR_01 標(biāo)記，如果重構(gòu)出錯(cuò)，就可以使用此標(biāo)記回退。你如果想生成整個(gè)項(xiàng)目的差異文件的話，也可以使用標(biāo)記。基本上，如今我們慣常使用提交的哈希值完成的事情都必須在 CVS 中提前計(jì)劃，因?yàn)槟惚仨毷紫扔袀€(gè)標(biāo)簽才行。
可以在 CVS 中創(chuàng)建分支。分支只是一種特殊的標(biāo)記，如下示：
$ cvs rtag -b TRY_EXPERIMENTAL_THING colors
cvs rtag: Tagging colors
這命令僅僅只是創(chuàng)建了分支（每個(gè)人都這樣覺得吧），所以還需要使用 cvs update 命令來切換分支，如下示：
$ cvs update -r TRY_EXPERIMENTAL_THING
上面的命令就會(huì)把你的當(dāng)前工作目錄切換到新的分支，但《Pragmatic Version Control Using CVS》一書實(shí)際上是建議創(chuàng)建一個(gè)新的目錄來房子你的新分支。估計(jì)，其作者發(fā)現(xiàn)在 CVS 里切換目錄要比切換分支來得更簡單吧。
此書也建議不要從現(xiàn)有分支創(chuàng)建分支，而只在主線分支（Git 中被叫做 master）上創(chuàng)建分支。一般來說，分支在 CVS 中主認(rèn)為是 “高級(jí)” 技能。而在 Git 中，你幾乎可以任性創(chuàng)建新分支，但 CVS 中要在真正需要的時(shí)候才能創(chuàng)建，比如發(fā)布項(xiàng)目。
稍后可以使用 cvs update 和 -j 標(biāo)志將分支合并回主線：
$ cvs update -j TRY_EXPERIMENTAL_THING
感謝歷史上的貢獻(xiàn)者
2007 年，Linus Torvalds 在 Google 進(jìn)行了一場關(guān)于 Git 的 演講 。當(dāng)時(shí) Git 是很新的東西，整場演講基本上都是在說服滿屋子都持有懷疑態(tài)度的程序員們：盡管 Git 是如此的與眾不同，也應(yīng)該使用 Git。如果沒有看過這個(gè)視頻的話，我強(qiáng)烈建議你去看看。Linus 是個(gè)有趣的演講者，即使他有些傲慢。他非常出色地解釋了為什么分布式的版本控制系統(tǒng)要比集中式的優(yōu)秀。他的很多評(píng)論是直接針對 CVS 的。
視頻地址： https://dn-linuxcn.qbox.me/static/video/Tech Talk – Linus Torvalds on git-4XpnKHJAok8.mp4
Git 是一個(gè) 相當(dāng)復(fù)雜的工具 。學(xué)習(xí)起來是一個(gè)令人沮喪的經(jīng)歷，但也不斷的給我驚喜：Git 還能做這樣的事情。相比之下，CVS 簡單明了，但是，許多我們認(rèn)為理所當(dāng)然的操作都做不了。想要對 Git 的強(qiáng)大功能和靈活性有全新的認(rèn)識(shí)的話，就回過頭來用用 CVS 吧，這是種很好的學(xué)習(xí)方式。這很好的詮釋了為什么理解軟件的開發(fā)歷史可以讓人受益匪淺。重拾過期淘汰的工具可以讓我們理解今天所使用的工具后面所隱藏的哲理。
如果你喜歡此博文的話，每兩周會(huì)有一次更新！請?jiān)?Twitter 上關(guān)注 @TwoBitHistory 或都通過 RSS feed 訂閱，新博文出來會(huì)有通知。
修正
有人告訴我，有很多組織企業(yè)，特別是像做醫(yī)療設(shè)備軟件等這種規(guī)避風(fēng)險(xiǎn)類的企業(yè)，仍在使用 CVS。這些企業(yè)中的程序員通過使用一些小技巧來解決 CVS 的限制，例如為幾乎每個(gè)更改創(chuàng)建一個(gè)新分支以避免直接提交給 HEAD。 （感謝 Michael Kohne 指出這一點(diǎn)。）
（題圖： plasticscm ）
via: https://twobithistory.org/2018/07/07/cvs.html
作者： Two-Bit History 選題： lujun9972 譯者： runningwater 校對： wxy
本文由 LCTT 原創(chuàng)編譯， Linux中國 榮譽(yù)推出
- “2015 Developer Survey,” Stack Overflow, accessed July 7, 2018, https://insights.stackoverflow.com/survey/2015#tech-sourcecontrol . ?
- Eric Sink, “A History of Version Control,” Version Control By Example, 2011, accessed July 7, 2018, https://ericsink.com/vcbe/html/history_of_version_control.html . ?
- Dick Grune, “Concurrent Versions System CVS,” dickgrune.com, accessed July 7, 2018, https://dickgrune.com/Programs/CVS.orig/#History . ?
- “Tech Talk: Linus Torvalds on Git,” YouTube, May 14, 2007, accessed July 7, 2018, https://www.youtube.com/watch?v=4XpnKHJAok8 . ?
- “Concurrent Versions System – News,” Savannah, accessed July 7, 2018, http://savannah.nongnu.org/news/?group=cvs . ?
