新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案

詳解CVS版本控制

CVS是一個C/S系統(tǒng)，多個開發(fā)人員通過一個中心版本控制系統(tǒng)來記錄文件版本，從而達(dá)到保證文件同步的目的。CVS版本控制系統(tǒng)是一種GNU軟件包，主要用于在多人開發(fā)環(huán)境下的源碼的維護(hù)。

image-20220107170916671

CVS 入門

CVS 的安裝教程可以在其項目主頁上找到。MacOS 系統(tǒng)的話，可以使用 Homebrew 安裝。

由于 CVS 是集中式的，所以它有客戶端和服務(wù)端之區(qū)分，這種模式 Git 是沒有的。兩端分別有不同的可執(zhí)行文件，其區(qū)別不太明顯。但要開始使用 CVS 的話，即使只在你的本地機器上使用，也必須設(shè)置 CVS 的服務(wù)后端。

CVS 的后端，即所有代碼的中央存儲區(qū)，被叫做存儲庫 repository。在 Git 中每一個項目都有一個存儲庫，而 CVS 中一個存儲庫就包含所有的項目。盡管有辦法保證一次只能訪問一個項目，但一個中央存儲庫包含所有東西是改變不了的。

要在本地創(chuàng)建存儲庫的話，請運行 init 命令。你可以像如下所示在家目錄創(chuàng)建，也可以在你本地的任何地方創(chuàng)建。

$ cvs -d ~/sandbox init

CVS 允許你將選項傳遞給 cvscvs 命令本身或 init 子命令。出現(xiàn)在cvs 命令之后的選項默認(rèn)是全局的，而出現(xiàn)在子命令之后的是子命令特有選項。上面所示例子中，-d 標(biāo)志是全局選項。在這兒是告訴 CVS 我們想要創(chuàng)建存儲庫路徑在哪里，但一般-d 標(biāo)志指的是我們想要使用的且已經(jīng)存在的存儲庫位置。一直使用 -d 標(biāo)志很單調(diào)乏味，所以可以設(shè)置 CVSROOT 環(huán)境變量來代替。

因為我們只是在本地操作，所以僅僅使用 -d 參考來傳遞路徑就可以，但也可以包含個主機名。

此命令在你的家目錄創(chuàng)建了一個名叫 sandbox 的目錄。如果你列出sandbox 內(nèi)容，會發(fā)現(xiàn)下面包含有名為 CVSROOT 的目錄。請不要把此目錄與我們的環(huán)境變量混淆，它保存存儲庫的管理文件。

恭喜！你剛剛創(chuàng)建了第一個 CVS 存儲庫。

檢入代碼

假設(shè)你決定留存下自己喜歡的顏色清單。因為你是一個有藝術(shù)傾向但很健忘的人，所以你鍵入顏色列表清單，并保存到一個叫 favorites.txt 的文件中：

blue
orange
green
definitely not yellow

我們也假設(shè)你把文件保存到一個叫colors 的目錄中?，F(xiàn)在你想要把喜歡的顏色列表清單置于版本控制之下，因為從現(xiàn)在起的五十年間你會回顧下，隨著時間的推移自己的品味怎么變化，這件事很有意思。

為此，你必須將你的目錄導(dǎo)入為新的 CVS 項目?？梢允褂胕mport 命令：

$ cvs -d ~/sandbox import -m "" colors colors initial
N colors/favorites.txt
No conflicts created by this import

這里我們再次使用-d 標(biāo)志來指定存儲庫的位置，其余的參數(shù)是傳輸給import 子命令的。必須要提供一條消息，但這兒沒必要，所以留空。下一個參數(shù)colors ，指定了存儲庫中新目錄的名字，這兒給的名字跟檢入的目錄名稱一致。最后的兩個參數(shù)分別指定了 “vendor” 標(biāo)簽和 “release” 標(biāo)簽。我們稍后就會談?wù)摌?biāo)簽。我們剛將 colors 項目拉入 CVS 存儲庫。將代碼引入 CVS 有很多種不同的方法，但這是《Pragmatic Version Control Using CVS》一書所推薦方法，這是一本關(guān)于 CVS 的程序員實用指導(dǎo)書籍。使用這種方法有點尷尬的就是你得重新檢出check out工作項目，即使已經(jīng)存在有 colors 此項目了。不要使用該目錄，首先刪除它，然后從 CVS 中檢出剛才的版本，如下示：

$ cvs -d ~/sandbox co colors
cvs checkout: Updating colors
U colors/favorites.txt

這個過程會創(chuàng)建一個新的目錄，也叫做 colors。此目錄里會發(fā)現(xiàn)你的源文件 favorites.txt，還有一個叫 CVS 的目錄。這個 CVS 目錄基本上與每個 Git 存儲庫的.git 目錄等價。

做出改動

準(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 沒有提交對象這一概念。如上示，有一個叫 “提交標(biāo)識符Commit Identifier” 的東西，但這可能是一個較新版本的標(biāo)識，在 2003 年出版的《Pragmatic Version Control Using CVS》一書中并沒有提到 “提交標(biāo)識符” 這個概念。（CVS 的最新版本于 2008 年發(fā)布的。5 ）

在 Git 中，我們所談?wù)撃澄募姹酒鋵嵤窃谡務(wù)撊?commit 45de392 相關(guān)的東西，而 CVS 中文件是獨立版本化的。文件的第一個版本為 1.1 版本，下一個是 1.2 版本，依此類推。涉及分支時，會在后面添加擴展數(shù)字。因此你會看到如上所示的 1.1.1.1 的內(nèi)容，這就是示例的版本號，即使我們沒有創(chuàng)建分支，似乎默認(rèn)的會給加上。

一個項目中會有很多的文件和很多次的提交，如果你運行 cvs log 命令（等同于 git log），會看到每個文件提交歷史信息。同一個項目中，有可能一個文件處于 1.2 版本，一個文件處于 1.14 版本。

繼續(xù)，我們對 1.1 版本的favorites.txt 文件做些修改（LCTT 譯注：原文此處示例有誤）：

blue
orange
green
cyan
definitely not yellow

修改完成，就可以運行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 識別出我們我在文件中添加了一個包含顏色 “cyan” 的新行。（實際上，它說我們已經(jīng)對 “RCS” 文件進(jìn)行了更改；你可以看到，CVS 底層使用的還是 RCS。）此差異指的是當(dāng)前工作目錄中的favorites.txt 副本與存儲庫中 1.1.1.1 版本的文件之間的差異。

為了更新存儲庫中的版本，我們必須提交更改。Git 中，這個操作要好幾個步驟。首先，暫存此修改，使其在索引中出現(xiàn)，然后提交此修改，最后，為了使此修改讓其他人可見，我們必須把此提交推送到源存儲庫中。

而 CVS 中，只需要運行 cvs commit 命令就搞定一切。CVS 會匯集它所找到的變化，然后把它們放到存儲庫中：

$ cvs commit -m "Add cyan to favorites."
cvs commit: Examining .
/Users/sinclairtarget/sandbox/colors/favorites.txt,v

我已經(jīng)習(xí)慣了 Git，所以這種操作會讓我感到十分恐懼。因為沒有變更暫存區(qū)的機制，工作目錄下任何你動過的東西都會一股腦給提交到公共存儲庫中。你有過因為不爽，私下里重寫了某個同事不佳的函數(shù)實現(xiàn)，但僅僅只是自我宣泄一下并不想讓他知道的時候嗎？如果不小心提交上去了，就太糟糕了，他會認(rèn)為你是個混蛋。在推送它們之前，你也不能對提交進(jìn)行編輯，因為提交就是推送。還是你愿意花費 40 分鐘的時間來反復(fù)運行 git rebase -i 命令，以使得本地提交歷史記錄跟數(shù)學(xué)證明一樣清晰嚴(yán)謹(jǐn)？很遺憾，CVS 里不支持，結(jié)果就是，大家都會看到你沒有先寫測試用例。

不過，到現(xiàn)在我終于理解了為什么那么多人都覺得 Git 沒必要搞那么復(fù)雜。對那些早已經(jīng)習(xí)慣直接 cvs commit 的人來說，進(jìn)行暫存變更和推送變更操作確實是毫無意義的差事。

人們常談?wù)?Git 是一個 “分布式” 系統(tǒng)，其中分布式與非分布式的主要區(qū)別為：在 CVS 中，無法進(jìn)行本地提交。提交操作就是向中央存儲庫提交代碼，所以沒有網(wǎng)絡(luò)連接，就無法執(zhí)行操作，你本地的那些只是你的工作目錄而已；在 Git 中，會有一個完完全全的本地存儲庫，所以即使斷網(wǎng)了也可以無間斷執(zhí)行提交操作。你還可以編輯那些提交、回退、分支，并選擇你所要的東西，沒有任何人會知道他們必須知道的之外的東西。

因為提交是個大事，所以 CVS 用戶很少做提交。提交會包含很多的內(nèi)容修改，就像如今我們能在一個含有十次提交的拉取請求中看到的一樣多。特別是在提交觸發(fā)了 CI 構(gòu)建和自動測試程序時如此。

現(xiàn)在我們運行cvs status ，會看到產(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 中，你可以同時編輯其他人正在編輯的文件。這是 CVS 對 RCS 的重大改進(jìn)。當(dāng)需要將更改的部分重新組合在一起時會發(fā)生什么？

假設(shè)你邀請了一些朋友來將他們喜歡的顏色添加到你的列表中。在他們添加的時候，你確定了不再喜歡綠色，然后把它從列表中刪除。

當(dāng)你提交更新的時候，會發(fā)現(xiàn) CVS 報出了個問題：

$ 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 文件版本沒有更新到存儲庫中的最新版本。此時運行cvs status 就可以看到，本地的 favorites.txt 文件副本有一些本地變更且是 1.2 版本的，而存儲庫上的版本號是 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)

你可以運行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

看來我們的朋友是真的喜歡粉紅色，但好在他們編輯的是此文件的不同部分，所以很容易地合并此修改。跟git pull 類似，只要運行 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

此時查看 favorites.txt 文件內(nèi)容的話，你會發(fā)現(xiàn)你的朋友對文件所做的更改已經(jīng)包含進(jìn)去了，你的修改也在里面?，F(xiàn)在你可以自由的提交文件了，如下示：

$ cvs commit
cvs commit: Examining .
/Users/sinclairtarget/sandbox/colors/favorites.txt,v

最終的結(jié)果就跟在 Git 中運行 git pull –rebase 一樣。你的修改是添加在你朋友的修改之后的，所以沒有 “合并提交” 這操作。

某些時候，對同一文件的修改可能導(dǎo)致沖突。例如，如果你的朋友把 “green” 修改成 “olive”，同時你完全刪除 “green”，就會出現(xiàn)沖突。CVS 早期的時候，正是這種情況導(dǎo)致人們擔(dān)心 CVS 不安全，而 RCS 的悲觀鎖機制可以確保此情況永不會發(fā)生。但 CVS 提供了一個安全保障機制，可以確保不會自動的覆蓋任何人的修改。因此，當(dāng)運行cvs update 的時候，你必須告訴 CVS 想要保留哪些修改才能繼續(xù)下一步操作。CVS 會標(biāo)記文件的所有變更，這跟 Git 檢測到合并沖突時所做的方式一樣，然后，你必須手工編輯文件，選擇需要保留的變更進(jìn)行合并。這兒需要注意的有趣事情就是在進(jìn)行提交之前必須修復(fù)并合并沖突。這是 CVS 集中式特性的另一個結(jié)果。而在 Git 里，在推送本地的提交內(nèi)容之前，你都不用擔(dān)心合并沖突問題。

標(biāo)記與分支

由于 CVS 沒有易于尋址的提交對象，因此對變更集合進(jìn)行分組的唯一方法就是對于特定的工作目錄狀態(tài)打個標(biāo)記。

創(chuàng)建一個標(biāo)記是很容易的：

$ cvs tag VERSION_1_0
cvs tag: Tagging .
T favorites.txt

稍后，運行 cvs update 命令并把標(biāo)簽傳輸給 -r 標(biāo)志就可以把文件恢復(fù)到此狀態(tài)，如下示：

$ cvs update -r VERSION_1_0
cvs update: Updating .
U favorites.txt

因為你需要一個標(biāo)記來回退到早期的工作目錄狀態(tài)，所以 CVS 鼓勵創(chuàng)建大量的搶先標(biāo)記。例如，在重大的重構(gòu)之前，你可以創(chuàng)建一個 BEFORE_REFACTOR_01 標(biāo)記，如果重構(gòu)出錯，就可以使用此標(biāo)記回退。你如果想生成整個項目的差異文件的話，也可以使用標(biāo)記?；旧希缃裎覀儜T常使用提交的哈希值完成的事情都必須在 CVS 中提前計劃，因為你必須首先有個標(biāo)簽才行。

可以在 CVS 中創(chuàng)建分支。分支只是一種特殊的標(biāo)記，如下示：

$ cvs rtag -b TRY_EXPERIMENTAL_THING colors
cvs rtag: Tagging colors

這命令僅僅只是創(chuàng)建了分支（每個人都這樣覺得吧），所以還需要使用 cvs update 命令來切換分支，如下示：

$ cvs update -r TRY_EXPERIMENTAL_THING

上面的命令就會把你的當(dāng)前工作目錄切換到新的分支，但《Pragmatic Version Control Using CVS》一書實際上是建議創(chuàng)建一個新的目錄來房子你的新分支。估計，其作者發(fā)現(xiàn)在 CVS 里切換目錄要比切換分支來得更簡單吧。

此書也建議不要從現(xiàn)有分支創(chuàng)建分支，而只在主線分支（Git 中被叫做 master）上創(chuàng)建分支。一般來說，分支在 CVS 中主認(rèn)為是 “高級” 技能。而在 Git 中，你幾乎可以任性創(chuàng)建新分支，但 CVS 中要在真正需要的時候才能創(chuàng)建，比如發(fā)布項目。

稍后可以使用 cvs update 和 -j 標(biāo)志將分支合并回主線：

$ cvs update -j TRY_EXPERIMENTAL_THING

修正

有人告訴我，有很多組織企業(yè)，特別是像做醫(yī)療設(shè)備軟件等這種規(guī)避風(fēng)險類的企業(yè)，仍在使用 CVS。這些企業(yè)中的程序員通過使用一些小技巧來解決 CVS 的限制，例如為幾乎每個更改創(chuàng)建一個新分支以避免直接提交給 HEAD。（感謝 Michael Kohne 指出這一點。）

文章標(biāo)題：詳解CVS版本控制
當(dāng)前URL：http://fisionsoft.com.cn/article/dpjppgg.html

新聞中心

CVS 入門

檢入代碼

做出改動

合并

標(biāo)記與分支

修正

其他資訊