基本介紹
- 中文名：CVS
- 外文名：Concurrent Version System
- 類別：代碼版本控制軟體
- 適用範圍：軟體開發
工作模式,工作思路,代碼配置,代碼調整,使用好處,替代管理,變化控制,自動測試,內置處理,術語,環境設定,日常使用,同步開發,遠程訪問,WEB,TAGS,Win,環境搭建,許可權管理,其他意思,發展,
工作模式
CVS（Concurrent Versions System）版本控制系統是一種GNU軟體包，主要用於在多人開發環境下源碼的維護。Concurrent有並發的、協作的、一致的等含義。實際上CVS可以維護任意文檔的開發和使用，例如已分享檔案的編輯修改，而不僅僅局限於程式設計。CVS維護的檔案類型可以是文本類型也可以是二進制類型。CVS用Copy-Modify-Merge（拷貝、修改、合併）變化表支持對檔案的同時訪問和修改。它明確地將源檔案的存儲和用戶的工作空間獨立開來，並使其並行操作。CVS基於客戶端/伺服器的行為使其可容納多個用戶。這一特性使得CVS成為位於不同地點的人同時處理數據檔案（特別是程式的原始碼）時的首選。
所有重要的免費軟體項目都使用CVS作為其程式設計師之間的中心點，以便能夠綜合各程式設計師的改進和更改。這些項目包括GNOME、KDE、THE GIMP和Wine等。
工作思路
在一台伺服器上建立一個原始碼庫，庫里可以存放許多不同項目的源程式。由原始碼庫管理員統一管理這些源程式。每個用戶在使用原始碼庫之前，首先要把原始碼庫里的項目檔案下載到本地，然後用戶可以在本地任意修改，最後用CVS命令進行提交，由CVS原始碼庫統一管理修改。這樣，就好像只有一個人在修改檔案一樣，既避免了衝突，又可以做到跟蹤檔案變化等。
CVS是並發版本系統（Concurrent Versions System）的意思，主流的開放源碼網路透明的版本控制系統。CVS對於從個人開發者到大型、分布團隊都是有用的。
它的客戶機/伺服器存取方法使得開發者可以從任何網際網路的接入點存取最新的代碼。它的無限制的版本管理檢出(check out：注1)的模式避免了通常的因為排它檢出模式而引起的人工衝突。它的客戶端工具可以在絕大多數的平台上使用。
CVS被套用於流行的開放源碼工程中，像Mozilla，GIMP，XEmacs，KDE和GNOME等。那么它到底怎么樣？
你可能會說，它非常棒，但是對於"我"來說它能做什麼？首先，基本的 ：一個版本控制系統保持了對一系列檔案所作改變的歷史記錄。對於一個開發者來說，那就意味著在你對一個程式所進行開發的整個期間，能夠跟蹤對其所作的所有改動的痕跡。對你來說，有沒有出現過由於在命令行上按錯鍵而導致一天的工作都白費的情況呢？版本控制系統給了你一個安全的網路。
版本控制系統對任何人都有用，真的。(畢竟，誰不願意使用一個安全的網路呢？)它們經常被軟體開發團隊使用。在團隊中工作的開發者需要能夠調整他們的各自的修改；一個集中式版本控制系統允許那樣做。
代碼配置
個人開發者希望一個版本控制系統的安全網路能夠運行在他們的本地的一台機器上。然而，開發團隊需要一個集中的伺服器，所有的成員可以將伺服器作為倉庫來訪問他們的代碼。在一個辦公室中，沒有問題 --只是將倉庫連到本地網路上的一台伺服器上就行了。對於開放源碼項目…噢， 還是沒有問題，這要感謝網際網路。CVS內建了客戶機/伺服器存取方法，所以任何一個可以連到網際網路上的開發者都可以存取在一台CVS伺服器上的檔案。
代碼調整
在傳統的版本控制系統中，一個開發者檢出一個檔案，修改它，然後將其登記回去。檢出檔案的開發者擁有對這個檔案修改的排它權。沒有其它的開發者可以檢出這個檔案-- 並且只有檢出那個檔案的開發者可以登記(check in：注2)所做的修改。(當然對於管理員有很多方法可以超越這個限制。)
想一下排它的檢出可能會如何工作：Bob的兄弟檢出 foo.java以便加入注釋，寫好代碼後他什麼也沒做。然後他去吃午飯了。Bob吃完午飯後，發現他的老闆所指給他的一個bug在 foo.java里。他試圖簽出 foo.java … 但是版本控制系統不允許他這樣做，因為他的兄弟已經把它簽出了。Bob不得不等著他的兄弟吃完午飯回來(在這個"好"日子用了兩個小時)，他才可以修正bug。
在一個大型的開放源碼工程中，因為開發者可能在任意的時區工作得很晚，給予一個開發者阻止任意地方的其它開發者繼續處理任意檔案的能力很明顯無法運轉。他們最終將因為不能夠在他們想要的時候開展項目而感到厭煩。
CVS通過它的無限制的簽出模式解決了這個問題。簽出一個檔案並不給定開發者對那個檔案的排它權。其它的開發者也可以對其檢出，進行他們自己的修改，並且將其登記回去。
"等一下！"你可能會說。"但是後面的登記不是會覆蓋前面的嗎？"回答是不會。詳細地回答就是當多個開發者對同一個檔案作了修改CVS會檢測，並且自動合併那些改變。
哇噢。自動的？不用擔心 -- CVS 會很小心，並且將會自動合併那些只要不是對代碼的同一行所作的改動。如果CVS不能安全的處理這些改動，開發者將不得不手工合併它們。從此去往何處？
有大量在許多平台上可用的CVS附加工具，它們給CVS增加了功能或使得CVS更容易使用。
使用好處
·修改軟體時可能會不知不覺混進一些bug，而且可能過了很久你才會察覺到它們的存在。有了 cvs，你可以很容易地恢復舊版本，並從中看出到底是哪個修改導致了這個bug。有時這是很有用的。
·cvs 用一種聰明的辦法把一個檔案的所有版本保存在一個檔案里，僅僅保存不同版本之間的差異。
·cvs 最初由 Dick Grune 在 1986 年 12 月以 shell腳本的形式發布在 comp.sources.unix 的新聞組第 6 卷里；1989 年 4 月，Brian Berliner 設計了 cvs 並編寫了代碼。之後 Jeff Polk 幫助 Brian 設計了 cvs 模組和銷售商分支支持。
·cvs 不能指導你如何構造什麼。它只是將你所設計的一種樹結構檔案保存下來以備恢復之用。
·cvs 不能決定如何在一個檢出工作目錄使用磁碟空間。如果你在每一個目錄中都寫下 Makefile 或腳本，且必須知道其它一切的相對位置，有時不得不檢出整個倉庫。
·如果你將你的工作模組化，並且建立了一個已分享檔案的 build 系統（通過links，mounts，Makefiles 里的 VPATH 等)，你就可以隨意安排磁碟的使用。
·你應該在 cvs 下放一個工具來支持這樣一個構造系統（腳本、Makefile 等等）。
·有些變化發生在 cvs 範圍之外時，要想想什麼檔案需要重建。一個傳統的方法是用 make 來構造，並用一些自動化的工具來產生 make 所用的相關檔案。
替代管理
你的經理和項目負責人應經常與你交流以確保你時時記得進度表、合併點、分支名和發布日期。如果他們不這樣做，cvs 也沒用。cvs 只是一個用來使你的資源與你的步調一致的工具。但你是風笛手和作曲家，沒有哪種樂器會自己演奏或是作曲。
·cvs 不能代替開發者之間的交流。
在單個檔案內遇到衝突時，大多數開發者不費多大力氣就能解決它們。但更常見的"衝突(conflict)"，是那些難度較大、不在開發者之間進行交流就沒法解決的問題。
當在一個檔案內或多個檔案中同時發生變化時，cvs 並不知道何時它們會在邏輯上發生衝突。它的衝突(conflict)概念是純粹文本意義上的，這種衝突會在同一個檔案的兩種變化十分接近以致於會破壞合併命令(如diff3)。
cvs 決不會指出程式邏輯上非文本或分散式的衝突。例如：假如你改變了在檔案A 中定義的函式X 的參數。同時，別人在編輯檔案B，仍用舊參數調用 X 這個函式。此時產生的衝突 cvs 可就無能為力了。
變化控制
變化控制可以指許多事情。首先它的意思可以是 BUG 跟蹤bug-tracking，就是說它能維持一個資料庫，其中包括已報告的 BUG 和每一個 BUG 狀態 (是否已更正？在哪一個版本中？提交這個 BUG 的人是否認為已經更正？)。為了使 cvs 和一個外部的跟蹤 BUG 系統協調一致，請參考 rcsinfo 和 verifymsg檔案(參閱 Administrative files)。
變化控制的另一個方面指跟蹤這樣的情況，即對好幾個檔案的改變實際上只是同一個邏輯變動。如果你在一次 cvs commit 操作中檢入幾個檔案，cvs 會忘掉它們是一起檢入的，它們共用一個 LOG 信息的事實只是把它們綁在一起而已。做一個 gnu 風格的 ChangeLog 可能會有點用。在一些系統中，變化控制的另一個方面是跟蹤每個變化的狀態的能力。一些變化由一個開發者寫出，而另一些變化則由另一個開發者來作出評論，等等。一般來講，用 cvs 來做，是產生一個 diff（用 cvs diff 或 diff），並且用電子郵件寄給某人，此人就可以用 patch 來套用它。這是非常靈活的，但依賴於 cvs 之外的機制以保證事情不會崩潰。
自動測試
強制利用 commitinfo檔案測試套件應該是可能的。不過我沒有聽說過多少項目試圖那樣做或那裡有微妙的陷阱。
內置處理
有些系統提供一些方法確保變更或發布通過不同的步驟，以及各種所需的批准過程。一般地，你可以用 cvs 來完成它，但是可能要多做點工作。有些情況下你想用 commitinfo、loginfo、rcsinfo 或 verifymsg檔案，要求在 CVS 提交之前完成某些操作。你也會考慮諸如 branches 和tags等特性是否能用在一個開發樹中執行任務，然後僅當它們被證實就把某些修改合併到一棵穩定的樹中。
CVS 還有一個更加重要的特性：能記下每個檔案的每次修改，以及如何被修改…對於基於 Internet 的合作方式來說，這些特性太重要了。一個地域上分散的自願者組織顯然不可能投入很多的時間來訓練其成員彼此合作。因為這樣的話，當該組織有成員變更的時候，為此付出的投資將損失殆盡。所以需要指定一套基本的項目分配方案，以確保新成員能較容易的適應工作，同時也需要設定一個自動的系統來接受外來代碼，並使每個成員能及時得到最新修改的代碼。
術語
Revision (修訂版本)－－檔案歷史記錄中的被開發者提交的變化。一個修訂版本就是一個時常變化的項目的 snapshot (瞬態圖)。
Repository (原始碼庫)－－CVS 存儲所有修訂版本歷史記錄的地方。每個項目都有自己的一個確定的原始碼庫。
Working copy (工作拷貝)－－開發者對檔案作出修改時檔案所在的拷貝。
Check out (檢驗)－－從原始碼庫中申請一份工作拷貝。該工作拷貝反映的是取出時項目的瞬時狀態。當開發者對拷貝作出修改時，必須運用 commit (提交)和 update (更新) 命令來 “發布”變化和查看其他開發者所作的修改。
Commit (提交)－－將工作拷貝中的變化輸入中央原始碼庫。
Log message (日誌信息)－－提交修訂版本的時候，附帶描述變化的註解。通過查閱記錄信息，人們可以獲得一個當前項目進程的總結。
Update (更新)－－從原始碼庫中取出別人的修改數據，將其輸入自己的工作拷貝，並顯示自己的工作拷貝是否有未提交的修改。注意，不要和 commit (提交)混淆，更新和提交是一對互補的指令。記住： Update 將使工作拷貝和原始碼庫拷貝保持同步更新。
Conflicts (衝突)－－兩個開發者對同一個區域所做的改動都提交給主版本時出現的情況，在 CVS 覺察並指出這個衝突後，開發者必須解決該衝突。
環境設定
tcsh
setenv CVSROOT /path/to/cvsroot
bash
CVSROOT=/path/to/cvsroot ; export CVSROOT
後面還提到遠程CVS伺服器的設定：
CVSROOT=:ext:[email protected]#port:/path/to/cvsroot CVS_RSH=ssh; export CVSROOT CVS_RSH
初始化：CVS版本庫的初始化。
cvs init
一個項目的首次導入
cvs import -m "write some comments here" project_name vendor_tag release_tag
執行後：會將所有源檔案及目錄導入到/path/to/cvsroot/project_name目錄下
vender_tag: 開發商標記
release_tag: 版本發布標記
項目導出：將代碼從CVS庫里導出
cvs checkout project_name
cvs 將創建project_name目錄，並將最新版本的原始碼導出到相應目錄中。這個checkout和Virvual SourceSafe中的check out不是一個概念，相對於Virvual SourceSafe的check out是cvs update， check in是cvs commit。
日常使用
注意：第一次導出以後，就不是通過cvs checkout來同步檔案了，而是要進入剛才cvs checkout project_name導出的project_name目錄下進行具體檔案的版本同步（添加，修改，刪除）操作。
將檔案同步到最新的版本cvs update
不制定檔案名稱，cvs將同步所有子目錄下的檔案，也可以制定某個檔案名稱/目錄進行同步
cvs update file_name
最好每天開始工作前或將自己的工作導入到CVS庫里前都要做一次，並養成“先同步 後修改”的習慣，和Virvual SourceSafe不同，CVS里沒有檔案鎖定的概念，所有的衝突是在commit之前解決，如果你修改過程中，有其他人修改並commit到了CVS 庫中，CVS會通知你檔案衝突，並自動將衝突部分用
>>>>>>
content on cvs server
<<<<<<
content in your file
>>>>>>
標記出來，由你確認衝突內容的取捨。
版本衝突一般是在多個人修改一個檔案造成的，但這種項目管理上的問題不應該指望由CVS來解決。
確認修改寫入到CVS庫里
cvs commit -m "write some comments here" file_name
注意：CVS的很多動作都是通過cvs commit進行最後確認並修改的，最好每次只修改一個檔案。在確認的前，還需要用戶填寫修改注釋，以幫助其他開發人員了解修改的原因。如果不用寫-m "comments"而直接確認`cvs commit file_name` 的話，cvs會自動調用系統預設的文字編輯器(一般是vi)要求你寫入注釋。
注釋的質量很重要：所以不僅必須要寫，而且必須寫一些比較有意義的內容：以方便其他開發人員能夠很好的理解
不好的注釋，很難讓其他的開發人員快速的理解：比如：-m "bugfixed" 甚至 -m ""
好的注釋，甚至可以用中文： -m "在用戶註冊過程中加入了Email地址校驗"
修改某個版本注釋：每次只確認一個檔案到CVS庫里是一個很好的習慣，但難免有時候忘了指定檔案名稱，把多個檔案以同樣注釋commit到CVS庫里了，以下命令可以允許你修改某個檔案某個版本的注釋：
cvs admin -m 1.3:"write some comments here" file_name
添加檔案
創建好新檔案後，比如：touch new_file
cvs add new_file
注意：對於圖片，Word文檔等非純文本的項目，需要使用cvs add -kb選項按2進制檔案方式導入(k表示擴展選項，b表示binary)，否則有可能出現檔案被破壞的情況
比如：
cvs add -kb new_file.gif
cvs add -kb readme.doc
如果關鍵字替換屬性在首次導入時設定錯了怎么辦？
cvs admin -kkv new_file.css
然後確認修改並注釋
cvs ci -m "write some comments here"
刪除檔案
將某個源檔案物理刪除後，比如：rm file_name
cvs rm file_name
然後確認修改並注釋
cvs ci -m "write some comments here"
以上面前2步合併的方法為：
cvs rm -f file_name
cvs ci -m "why delete file"
注意：很多cvs命令都有縮寫形式：commit=>ci; update=>up; checkout=>co/get; remove=>rm;
添加目錄
cvs add dir_name
查看修改歷史
cvs log file_name
cvs history file_name
查看當前檔案不同版本的區別
cvs diff -r1.3 -r1.5 file_name
查看當前檔案（可能已經修改了）和庫中相應檔案的區別
cvs diff file_name
cvs的web界面提供了更方便的定位檔案修改和比較版本區別的方法，具體安裝設定請看後面的cvsweb使用
正確的通過CVS恢復舊版本的方法：
如果用cvs update -r1.2 file.nam e
這個命令是給file.n ame加一個STICK TAG："1.2" ，雖然你的本意只是想將它恢復到1.2版本
正確的恢復版本的方法是：cvs update -p -r1.2 file_name >file_name
如果不小心已經加成STICK TAG的話：用cvs update -A 解決
移動檔案/檔案重命名
cvs里沒有cvs move或cvs rename，因為這兩個操作是可以由先cvs remove old_file_name，然後cvs add new_file_name實現的。
刪除/移動目錄
最方便的方法是讓管理員直接移動，刪除CVSROOT里相應目錄（因為CVS一個項目下的子目錄都是獨立的，移動到$CVSROOT目錄下都可以作為新的獨立項目：好比一顆樹，其實砍下任意一枝都能獨立存活），對目錄進行了修改後，要求其開發人員重新導出項目cvs checkout project_name 或者用cvs update -dP同步。
項目發布導出不帶CVS目錄的源檔案
做開發的時候你可能注意到了，每個開發目錄下，CVS都創建了一個CVS/目錄。裡面有檔案用於記錄當前目錄和CVS庫之間的對應信息。但項目發布的時候你一般不希望把檔案目錄還帶著含有CVS信息的CVS目錄吧，這個一次性的導出過程使用cvs export命令，不過export只能針對一個TAG或者日期導出，比如：
cvs export -r release1 project_name
cvs export -D 20021023 project_name
cvs export -D now project_name
同步開發
分支適用於什麼情況
假定 tc 的發行版 1.0 已完成。你正在繼續開發 tc，計畫在 2 個月後創建發行 1.1 的版本。不久你的客戶開始抱怨說代碼有些問題。你檢出了 1.0 的發行版(參閱Tags)，找到了這個錯誤（這將會有一個小小的更正）。但是，當前代碼的版本是處在一個不穩的狀態， 並且在下一個月才能有希望穩定下來。這樣就沒法基於最新原始碼去發行一個修復錯誤的版本。這種情況下就可以去為所有構成 tc 的 1.0 發行版檔案創建版本樹的一個分支（branch）。然後你可以修改這分支而不影響到主幹。當修訂完成時，你可以選定是否要把它同主幹合併或繼續保留在這個分支里。
確認版本里程碑：多個檔案各自版本號不一樣，項目到一定階段，可以給所有檔案統一指定一個階段里程碑版本號，方便以後按照這個階段里程碑版本號導出項目，同時也是項目的多個分支開發的基礎。
cvs tag release_1_0
開始一個新的里程碑：
cvs commit -r 2 標記所有檔案開始進入2.x的開發
注意：CVS里的revsion和軟體包的發布版本可以沒有直接的關係。但所有檔案使用和發布版本一致的版本號比較有助於維護。
版本分支的建立
在開發項目的2.x版本的時候發現1.x有問題，但2.x又不敢用，則從先前標記的里程碑：release_1_0導出一個分支 release_1_0_patch
cvs rtag -b -r release_1_0 release_1_0_patch proj_dir
一些人先在另外一個目錄下導出release_1_0_patch這個分支：解決1.0中的緊急問題，
cvs checkout -r release_1_0_patch
而其他人員仍舊在項目的主幹分支2.x上開發
在release_1_0_patch上修正錯誤後，標記一個1.0的錯誤修正版本號
cvs tag release_1_0_patch_1
如果2.0認為這些錯誤修改在2.0里也需要，也可以在2.0的開發目錄下合併release_1_0_patch_1中的修改到當前代碼中：
cvs update -j release_1_0_patch_1
遠程訪問
使用cvs本身基於pserver的遠程認證很麻煩，需要定義伺服器和用戶組，用戶名，設定密碼等，
常見的登入格式如下：
cvs -d :pserver:[email protected]:/path/to/cvsroot login
例子：
cvs -d :pserver:cvs@sam ba.or g:/cvsroot login
不是很安全，因此一般是作為匿名唯讀CVS訪問的方式。從安全考慮，通過系統本地帳號認證並通過SSH傳輸是比較好的辦法，通過在客戶機的 /etc/profile里設定一下內容：
CVSROOT=:ext:[email protected]#port:/path/to/cvsroot CVS_RSH=ssh; export CVSROOT CVS_RSH
比如：
CVS伺服器是192.168.0.3，上面CVSROOT路徑是/home/cvsroot，另外一台開發客戶機是192.168.0.4，如果 tom在2台機器上都有同名的帳號，那么從192.168.0.4上設定了：
export CVSROOT=:ext:[email protected]:/home/cvsroot
export CVS_RSH=ssh
tom就可以直接在192.168.0.4上對192.168.0.3的cvsroot進行訪問了（如果有許可權的話）
cvs checkout project_name
cd project_name
cvs update
…
cvs commit
如果CVS所在伺服器的SSH連線埠不在預設的22，或者和客戶端與CVS伺服器端SSH預設連線埠不一致，有時候設定了：
:ext:[email protected]#port:/path/to/cvsroot
仍然不行，比如有以下錯誤信息：
ssh: test.server.address#port: Name or service not known
cvs [checkout aborted]: end of file from server (consult above messages if any)
解決的方法是做一個腳本指定連線埠轉向（不能使用alias，會出找不到檔案錯誤）：
創建一個/usr/bin/ssh_cvs檔案，假設遠程伺服器的SSH連線埠是非預設連線埠：34567
#!/bin/sh
/usr/bin/ssh -p 34567 "$@"
然後：chmod +x /usr/bin/ssh_cvs
並CVS_RSH=ssh_cvs; export CVS_RSH
注意：port是指相應伺服器SSH的連線埠，不是指cvs專用的pserver的連線埠
WEB
CVSWEB就是CVS的WEB界面，可以大大提高程式設計師定位修改的效率：
CVSWEB的下載：CVSWEB從最初的版本已經演化出很多功能界面更豐富的版本，這個是我個人感覺安裝設定比較方便的：
下載解包：
tar zxf cvsweb.tgz
把配置檔案cvsweb.conf放到安全的地方（比如和apache的配置放在同一個目錄下），
修改：cvsweb.cgi讓CGI找到配置檔案：
$config = $ENV{'CVSWEB_CONFIG'} || '/path/to/apache/conf/cvsweb.conf';
轉到/path/to/apache/conf下並修改cvsweb.conf：
修改CVSROOT路徑設定：%CVSROOT = ('Development' => '/path/to/cvsroot',#<==修改指向本地的CVSROOT); 預設不顯示已經刪除的文檔："hideattic" => "1",#<==預設不顯示已經刪除的文檔 在配置檔案cvsweb.conf中還可以定製頁頭的描述信息，你可以修改$long_intro成你需要的文字 CVSWEB可不能隨便開放給所有用戶，因此需要使用WEB用戶認證：
先生成 passwd:
/path/to/apache/bin/htpasswd -c cvsweb.passwd user
修改httpd.conf: 增加
<Directory "/path/to/apache/cgi-bin/cvsweb/">
AuthName "CVS Authorization"
AuthType Basic
AuthUserFile /path/to/cvsweb.passwd
require valid-user
</Directory>
TAGS
將$Id: cvs_card.html,v 1.9 2003/11/09 07:57:11 chedong Exp $ 加在程式檔案開頭的注釋里是一個很好的習慣，cvs能夠自動解釋更新其中的內容成：file_name version time user_name 的格式，比如：cvs_card.txt,v 1.1 2002/04/05 04:24:12 chedong Exp，可以這些信息了解檔案的最後修改人和修改時間
幾個常用的預設檔案：default.php<?php/* * Copyright (c) 2002 Company Name. * $Header: /home/cvsroot/tech/cvs_card.html,v 1.9 2003/11/09 07:57:11 chedong Exp $ */?>====================================Default.java: 注意檔案頭一般注釋用 /* 開始 JAVADOC注釋用 /** 開始的區別/* * Copyright (c) 2002 MyCompany Name. * $Header: /home/cvsroot/tech/cvs_card.html,v 1.9 2003/11/09 07:57:11 chedong Exp $ */package com.mycompany;import java.;/** * comments here */public class Default { /** * Comments here * @param * @return */ public toString() { }}====================================de fa ult. pl:#!/usr/bin/perl -w# Copyright (c) 2002 Company Name.# $Header: /home/cvsroot/tech/cvs_card.html,v 1.9 2003/11/09 07:57:11 chedong Exp $# file comments hereuse strict;CVS-CVS vs VSS CVS沒有檔案鎖定模式，VSS在check out同時，同時記錄了檔案被導出者鎖定。
CVS的update和commit， VSS是get_lastest_version和check in
對應VSS的check out/undo check out的CVS里是edit和unedit
在CVS中，標記自動更新功能預設是打開的，這樣也帶來一個潛在的問題，就是不用-kb方式添加binary檔案的話在cvs自動更新時可能會導致檔案失效。
$Header: /home/cvsroot/tech/cvs_card.html,v 1.5 2003/03/09 08:41:46 chedong Exp $ $Date: 2003/11/09 07:57:11 $這樣的標記在Virsual SourceSafe中稱之為Keyword Explaination，預設是關閉的，需要通過OPITION打開，並指定需要進行源檔案關鍵字掃描的檔案類型：*.txt,*.java,*.html…
對於Virsual SourceSafe和CVS都通用的TAG有：
$Header: /home/cvsroot/tech/cvs_card.html,v 1.5 2003/03/09 08:41:46 chedong Exp $
$Author: chedong $
$Date: 2003/11/09 07:57:11 $
$Revision: 1.9 $
我建議儘量使用通用的關鍵字保證代碼在CVS和VSS都能方便的跟蹤。
Win
下載
cvs Windows客戶端：穩定版本為1.2
ssh Windows客戶端
安裝好以上2個軟體以後：
WinCVS客戶端的admin==>preference設定
1．在general選單里
設定CVSROOT：[email protected]:/home/cvsroot
設定Authorization: 選擇SSH server
2．Port選單里
鉤上：check for alternate rsh name
並設定ssh.exe的路徑，預設是裝在 C:\Program Files\NetworkSimplicity\ssh\ssh.exe
然後就可以使用WinCVS進行cvs操作了，所有操作都會跳出命令行視窗要求你輸入伺服器端的認證密碼。
可以選擇的diff工具：examdiff
還是在WinCVS選單admin==>preference的WinCVS選單里
選上：Externel diff program
並設定diff工具的路徑，比如：C:\Program Files\ed16i\ExamDiff.exe
在對檔案進行版本diff時，第一次需要將視窗右下角的use externel diff選上。
環境搭建
作為一個小組級的開發環境，版本控制系統和BUG跟蹤系統等都涉及到用戶認證部分。如何方便的將這些系統集成起來是一個非常困難的事情，畢竟我們不能指望 Linux下有像Source Offsite那樣集成度很高的版本控制/BUG跟蹤集成系統。
我個人是很反對使用pserver模式的遠程用戶認證的，但如果大部分組員使用WINDOWS客戶端進行開發的話，總體來說使用 CVSROOT/passwd認證還是很難避免的，但CVS本身用戶的管理比較麻煩。本來我打算自己用perl寫一個管理界面的，直到我發現了 CVSTrac：一個基於WEB界面的BUG跟蹤系統，它外掛在CVS系統上的BUG跟蹤系統，其中就包括了WEB界面的CVSROOT/passwd檔案的管理，甚至還集成了WIKIWIKI討論組功能。這裡首先說一下CVS的pserver模式下的用戶認證，CVS的用戶認證服務是基於inetd中的：
cvspserver stream tcp nowait apache /usr/bin/cvs cvs --allow-root=/home/cvsroot pserver
一般在2401連線埠（這個連線埠號很好記：49的平方）
CVS用戶資料庫是基於CVSROOT/passwd檔案，檔案格式：
[username]:[crypt_password]:[mapping_system_user]
由於密碼都用的是UNIX標準的CRYPT加密，這個passwd檔案的格式基本上是apache的htpasswd格式的擴展（比APACHE的 PASSWD檔案多一個系統用戶映射欄位），所以這個檔案最簡單的方法可以用
apache/bin/htpasswd -b myname mypassword
創建。注意：通過htpasswd創建出來的檔案會沒有映射系統用戶的欄位
例如：
new:geBvosup/zKl2
setup:aISQuNAAoY3qw
test:hwEpz/BX.rEDU
映射系統用戶的目的在於：你可以創建一個專門的CVS服務帳號，比如用apache的運行用戶apache，並將/home/cvsroot目錄下的所有許可權賦予這個用戶，然後在passwd檔案里創建不同的開發用戶帳號，但開發用戶帳號最後的檔案讀寫許可權都映射為apache用戶，在SSH模式下多個系統開發用戶需要在同一個組中才可以相互讀寫CVS庫中的檔案。
進一步的，你可以將用戶分別映射到apache這個系統用戶上。
new:geBvosup/zKl2:apache
setup:aISQuNAAoY3qw:apache
test:hwEpz/BX.rEDU:apache
CVSTrac很好的解決了CVSROOT/passwd的管理問題，而且包含了BUG跟蹤報告系統和集成WIKIWIKI交流功能等，使用的 CGI方式的安裝，並且基於GNU Public License：
在inetd里加入cvspserver服務：
cvspserver stream tcp nowait apache /usr/bin/cvs cvs --allow-root=/home/cvsroot pserver
xietd的配置檔案：%cat cvspserver
service cvspserver
{
disable = no
socket_type = stream
wait = no
user = apache
server = /usr/bin/cvs
server_args = -f --allow-root=/home/cvsroot pserver
log_on_failure += USERID
}
注意：這裡的用戶設定成apache目的是和/home/cvsroot的所有用戶一致，並且必須讓這個這個用戶對/home/cvsroot/下的 CVSROOT/passwd和cvstrac初始化生成的myproj.db有讀取許可權。
安裝過程
假設資料庫名是 myproj在已經裝好的CVS伺服器上（CVS庫這時候應該已經是初始化好了，比如：cvs init初始化在/home/cvsroot里），運行一下%cvstrac init /home/cvsroot myproj運行後，/home/cvsroot里會有一個的myproj.db庫，使用CVSTRAC服務，/home/cvsroot/myproj.db /home/cvsroot/CVSROOT/readers /home/cvsroot/CVSROOT/writers /home/cvsroot/CVSROOT/passwd這幾個檔案對於web服務的運行用戶應該是可寫的，在RedHat8上，預設就有一個叫 apache用戶和一個apache組，所以在httpd.conf檔案中設定了用apache用戶運行web服務：User apacheGroup apache，然後設定屬於apache用戶和apache組#chown -R apache:apache /home/cvsroot-rw-r--r-- 1 apache apache 55296 Jan 5 19:40 myproj.dbdrwxrwxr-x 3 apache apache 4096 Oct 24 13:04 CVSROOT/drwxrwxr-x 2 apache apache 4096 Aug 30 19:47 some_proj/此外還在/home/cvsroot/CVSROOT中設定了：chmod 664 readers writers passwd在apche/cgi-bin目錄中創建腳本cvstrac:#!/bin/sh/usr/bin/cvstrac cgi /home/cvsroot設定腳本可執行：chmod +x /home/apache/cgi-bin/cvstrac從http://cvs.server.address/cgi-bin/cvstrac/myproj進入管理界面預設登錄名：setup 密碼 setup對於一般用戶可以從：http://cvs.server.address/cgi-bin/cvstrac/myproj在setup中重新設定了CVSROOT的路徑後，/home/cvsroot如果是初次使用需要在/home/cvsroot/CVSROOT下創建passwd,readers,writers檔案touch passwd readers writers然後設定屬於apache用戶，chown apache.apache passwd readers writers這樣使用setup用戶創建新用戶後會同步更新CVSROOT/passwd下的帳號修改登錄密碼，進行BUG報告等，
更多使用細節可以在使用中慢慢了解。
對於前面提到的WinCVS在perference里設定：
CVSROOT欄輸入：[email protected]:/home/cvsroot
Authenitication選擇：use passwd file on server side
就可以了從伺服器上進行CVS操作了。
許可權管理
CVS的許可權管理分2種策略
基於系統檔案許可權的系統用戶管理：適合多個在Linux上使用系統帳號的開發人員進行開發。基於CVSROOT/passwd的虛擬用戶管理：適合多個在Windows平台上的開發人員將帳號映射成系統帳號使用。為什麼使用apache/apache用戶？首先RedHat8中預設就有了，而且使用這個用戶可以方便通過cvstrac進行WEB管理。
chown -R apache.apache /home/cvsroot
chmod 775 /home/cvsroot
Linux上通過ssh連線CVS伺服器的多個開發人員：通過都屬於apache組實現檔案的共享讀寫
開發人員有開發伺服器上的系統帳號：sysuser1 sysuser2，設定讓他們都屬於apache組，因為通過cvs新導入的項目都是對組開放的：664許可權的，這樣無論那個系統用戶導入的項目檔案，只要檔案的組宿主是apache，所有其他同組系統開發用戶就都可以讀寫；基於ssh遠程認證的也是一樣。
apache(system group)
/ | \
sysuser1 sysuser2 sysuser3
Windows上通過cvspserver連線CVS伺服器的多個開發人員：通過在passwd檔案種映射成 apache用戶實現檔案的共享讀寫
他們的帳號通過CVSROOT/passwd和readers writers這幾個檔案管理；通過cvstrac設定所有虛擬用戶都映射到apache用戶上即可。
apache(system user)
/ | \
windev1 windev2 windev3
利用CVS WinCVS/CVSWeb/CVSTrac 構成了一個相對完善的跨平台工作組開發版本控制環境。
其他意思
Constant Volume Sample 為汽車排放氣體定容採樣測試
CVS（CVS Caremark）美國第二大連鎖藥店
CVS 在PCB行業中是一種名為電鍍添加劑分析儀的儀器
三角函式中的余矢函式(coversine)的縮寫
心血管系統（cardiovascularsystem）。
CVS（Convenience Store）便利店
CVS——亂鬥格鬥遊戲CAPCOM VS SNK的縮寫。
