溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇文章主要介紹了CVS版本控制方法是什么的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇CVS版本控制方法是什么文章都會有所收獲，下面我們一起來看看吧。
CVS是一個C/S系統，多個開發人員通過一個中心版本控制系統來記錄文件版本，從而達到保證文件同步的目的。CVS版本控制系統是一種GNU軟件包，主要用于在多人開發環境下的源碼的維護。
由于 CVS 是集中式的，所以它有客戶端和服務端之區分，這種模式 Git 是沒有的。兩端分別有不同的可執行文件，其區別不太明顯。但要開始使用 CVS 的話，即使只在你的本地機器上使用，也必須設置 CVS 的服務后端。
CVS 的后端，即所有代碼的中央存儲區，被叫做存儲庫 repository。在 Git 中每一個項目都有一個存儲庫，而 CVS 中一個存儲庫就包含所有的項目。盡管有辦法保證一次只能訪問一個項目，但一個中央存儲庫包含所有東西是改變不了的。
要在本地創建存儲庫的話，請運行 init 命令。你可以像如下所示在家目錄創建，也可以在你本地的任何地方創建。
$ cvs -d ~/sandbox init
CVS 允許你將選項傳遞給 cvscvs 命令本身或 init 子命令。出現在cvs 命令之后的選項默認是全局的，而出現在子命令之后的是子命令特有選項。上面所示例子中，-d 標志是全局選項。在這兒是告訴 CVS 我們想要創建存儲庫路徑在哪里，但一般-d 標志指的是我們想要使用的且已經存在的存儲庫位置。一直使用 -d 標志很單調乏味，所以可以設置 CVSROOT 環境變量來代替。
因為我們只是在本地操作，所以僅僅使用 -d 參考來傳遞路徑就可以，但也可以包含個主機名。
此命令在你的家目錄創建了一個名叫 sandbox 的目錄。 如果你列出sandbox 內容，會發現下面包含有名為 CVSROOT 的目錄。請不要把此目錄與我們的環境變量混淆，它保存存儲庫的管理文件。
恭喜！ 你剛剛創建了第一個 CVS 存儲庫。
假設你決定留存下自己喜歡的顏色清單。因為你是一個有藝術傾向但很健忘的人，所以你鍵入顏色列表清單，并保存到一個叫 favorites.txt 的文件中：
blue orange green definitely not yellow
我們也假設你把文件保存到一個叫colors 的目錄中。現在你想要把喜歡的顏色列表清單置于版本控制之下，因為從現在起的五十年間你會回顧下，隨著時間的推移自己的品味怎么變化，這件事很有意思。
為此，你必須將你的目錄導入為新的 CVS 項目。可以使用import 命令：
$ cvs -d ~/sandbox import -m "" colors colors initial N colors/favorites.txt No conflicts created by this import
這里我們再次使用-d 標志來指定存儲庫的位置，其余的參數是傳輸給import 子命令的。必須要提供一條消息，但這兒沒必要，所以留空。下一個參數colors ，指定了存儲庫中新目錄的名字，這兒給的名字跟檢入的目錄名稱一致。最后的兩個參數分別指定了 “vendor” 標簽和 “release” 標簽。我們稍后就會談論標簽。 我們剛將 colors 項目拉入 CVS 存儲庫。將代碼引入 CVS 有很多種不同的方法，但這是 《Pragmatic Version Control Using CVS》 一書所推薦方法，這是一本關于 CVS 的程序員實用指導書籍。使用這種方法有點尷尬的就是你得重新檢出check out工作項目，即使已經存在有 colors 此項目了。不要使用該目錄，首先刪除它，然后從 CVS 中檢出剛才的版本，如下示：
$ cvs -d ~/sandbox co colors cvs checkout: Updating colors U colors/favorites.txt
這個過程會創建一個新的目錄，也叫做 colors。此目錄里會發現你的源文件 favorites.txt，還有一個叫 CVS 的目錄。這個 CVS 目錄基本上與每個 Git 存儲庫的.git 目錄等價。
準備旅行。
和 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 沒有提交對象這一概念。如上示，有一個叫 “提交標識符Commit Identifier” 的東西，但這可能是一個較新版本的標識，在 2003 年出版的《Pragmatic Version Control Using CVS》一書中并沒有提到 “提交標識符” 這個概念。 （CVS 的最新版本于 2008 年發布的。5 ）
在 Git 中，我們所談論某文件版本其實是在談論如 commit 45de392 相關的東西，而 CVS 中文件是獨立版本化的。文件的第一個版本為 1.1 版本，下一個是 1.2 版本，依此類推。涉及分支時，會在后面添加擴展數字。因此你會看到如上所示的 1.1.1.1 的內容，這就是示例的版本號，即使我們沒有創建分支，似乎默認的會給加上。
一個項目中會有很多的文件和很多次的提交，如果你運行 cvs log 命令（等同于 git log），會看到每個文件提交歷史信息。同一個項目中，有可能一個文件處于 1.2 版本，一個文件處于 1.14 版本。
繼續，我們對 1.1 版本的favorites.txt 文件做些修改（LCTT 譯注：原文此處示例有誤）：
blue orange green cyan definitely not yellow
修改完成，就可以運行cvs diff 來看看 CVS 發生了什么：
$ 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” 的新行。（實際上，它說我們已經對 “RCS” 文件進行了更改；你可以看到，CVS 底層使用的還是 RCS。） 此差異指的是當前工作目錄中的favorites.txt 副本與存儲庫中 1.1.1.1 版本的文件之間的差異。
為了更新存儲庫中的版本，我們必須提交更改。Git 中，這個操作要好幾個步驟。首先，暫存此修改，使其在索引中出現，然后提交此修改，最后，為了使此修改讓其他人可見，我們必須把此提交推送到源存儲庫中。
而 CVS 中，只需要運行 cvs commit 命令就搞定一切。CVS 會匯集它所找到的變化，然后把它們放到存儲庫中：
$ cvs commit -m "Add cyan to favorites."cvs commit: Examining . /Users/sinclairtarget/sandbox/colors/favorites.txt,v
我已經習慣了 Git，所以這種操作會讓我感到十分恐懼。因為沒有變更暫存區的機制，工作目錄下任何你動過的東西都會一股腦給提交到公共存儲庫中。你有過因為不爽，私下里重寫了某個同事不佳的函數實現，但僅僅只是自我宣泄一下并不想讓他知道的時候嗎？如果不小心提交上去了，就太糟糕了，他會認為你是個混蛋。在推送它們之前，你也不能對提交進行編輯，因為提交就是推送。還是你愿意花費 40 分鐘的時間來反復運行 git rebase -i 命令，以使得本地提交歷史記錄跟數學證明一樣清晰嚴謹？很遺憾，CVS 里不支持，結果就是，大家都會看到你沒有先寫測試用例。
不過，到現在我終于理解了為什么那么多人都覺得 Git 沒必要搞那么復雜。對那些早已經習慣直接 cvs commit 的人來說，進行暫存變更和推送變更操作確實是毫無意義的差事。
人們常談論 Git 是一個 “分布式” 系統，其中分布式與非分布式的主要區別為：在 CVS 中，無法進行本地提交。提交操作就是向中央存儲庫提交代碼，所以沒有網絡連接，就無法執行操作，你本地的那些只是你的工作目錄而已；在 Git 中，會有一個完完全全的本地存儲庫，所以即使斷網了也可以無間斷執行提交操作。你還可以編輯那些提交、回退、分支，并選擇你所要的東西，沒有任何人會知道他們必須知道的之外的東西。
因為提交是個大事，所以 CVS 用戶很少做提交。提交會包含很多的內容修改，就像如今我們能在一個含有十次提交的拉取請求中看到的一樣多。特別是在提交觸發了 CI 構建和自動測試程序時如此。
現在我們運行cvs status ，會看到產生了文件的新版本：
$ 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 的重大改進。當需要將更改的部分重新組合在一起時會發生什么？
假設你邀請了一些朋友來將他們喜歡的顏色添加到你的列表中。在他們添加的時候，你確定了不再喜歡綠色，然后把它從列表中刪除。
當你提交更新的時候，會發現 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 文件內容的話，你會發現你的朋友對文件所做的更改已經包含進去了，你的修改也在里面。現在你可以自由的提交文件了，如下示：
$ cvs commit cvs commit: Examining . /Users/sinclairtarget/sandbox/colors/favorites.txt,v
最終的結果就跟在 Git 中運行 git pull –rebase 一樣。你的修改是添加在你朋友的修改之后的，所以沒有 “合并提交” 這操作。
某些時候，對同一文件的修改可能導致沖突。例如，如果你的朋友把 “green” 修改成 “olive”，同時你完全刪除 “green”，就會出現沖突。CVS 早期的時候，正是這種情況導致人們擔心 CVS 不安全，而 RCS 的悲觀鎖機制可以確保此情況永不會發生。但 CVS 提供了一個安全保障機制，可以確保不會自動的覆蓋任何人的修改。因此，當運行cvs update 的時候，你必須告訴 CVS 想要保留哪些修改才能繼續下一步操作。CVS 會標記文件的所有變更，這跟 Git 檢測到合并沖突時所做的方式一樣，然后，你必須手工編輯文件，選擇需要保留的變更進行合并。 這兒需要注意的有趣事情就是在進行提交之前必須修復并合并沖突。這是 CVS 集中式特性的另一個結果。而在 Git 里，在推送本地的提交內容之前，你都不用擔心合并沖突問題。
由于 CVS 沒有易于尋址的提交對象，因此對變更集合進行分組的唯一方法就是對于特定的工作目錄狀態打個標記。
創建一個標記是很容易的：
$ cvs tag VERSION_1_0 cvs tag: Tagging . T favorites.txt
稍后，運行 cvs update 命令并把標簽傳輸給 -r 標志就可以把文件恢復到此狀態，如下示：
$ cvs update -r VERSION_1_0 cvs update: Updating . U favorites.txt
因為你需要一個標記來回退到早期的工作目錄狀態，所以 CVS 鼓勵創建大量的搶先標記。例如，在重大的重構之前，你可以創建一個 BEFORE_REFACTOR_01 標記，如果重構出錯，就可以使用此標記回退。你如果想生成整個項目的差異文件的話，也可以使用標記。基本上，如今我們慣常使用提交的哈希值完成的事情都必須在 CVS 中提前計劃，因為你必須首先有個標簽才行。
可以在 CVS 中創建分支。分支只是一種特殊的標記，如下示：
$ cvs rtag -b TRY_EXPERIMENTAL_THING colors cvs rtag: Tagging colors
這命令僅僅只是創建了分支（每個人都這樣覺得吧），所以還需要使用 cvs update 命令來切換分支，如下示：
$ cvs update -r TRY_EXPERIMENTAL_THING
上面的命令就會把你的當前工作目錄切換到新的分支，但《Pragmatic Version Control Using CVS》一書實際上是建議創建一個新的目錄來房子你的新分支。估計，其作者發現在 CVS 里切換目錄要比切換分支來得更簡單吧。
此書也建議不要從現有分支創建分支，而只在主線分支（Git 中被叫做 master）上創建分支。一般來說，分支在 CVS 中主認為是 “高級” 技能。而在 Git 中，你幾乎可以任性創建新分支，但 CVS 中要在真正需要的時候才能創建，比如發布項目。
稍后可以使用 cvs update 和 -j 標志將分支合并回主線：
$ cvs update -j TRY_EXPERIMENTAL_THING
關于“CVS版本控制方法是什么”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“CVS版本控制方法是什么”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
