CVS

CVS伺服器（文件版本庫）

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伺服器相應同名帳號了。

比如：

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的埠

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: 增加

AuthName "CVS Authorization"

AuthType Basic

AuthUserFile /path/to/cvsweb.passwd

require valid-user

將$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====================================Default.java: 注意文件頭一般註釋用 package com.mycompany;import java.;public class Default { 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都能方便的跟蹤。

下載

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操作了，所有操作都會跳出命令行窗口要求你輸入伺服器端的認證密碼。

當然，如果你覺得這樣很煩的話，還有一個辦法就是生成一個沒有密碼的公鑰/私鑰對，並設置CVS使用基於公鑰/私鑰的SSH認證（在general 選單里）。

可以選擇的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)的縮寫

心血管系統（ cardio vascular system）。

CVS（Convenience Store）便利店

CVS——亂斗格鬥遊戲CAPCOM VS SNK的縮寫。

20世紀90年代初期，Jim kingdon最終將CVs設計成基於網路的平台，因此開發者們能從網際網路上的任何地方獲得程序源代碼。這使得基本代碼對所有感興趣的人開放了。由於CVs能巧妙地對相同文件的變化進行合併，開發者也就無需為很多的人在同一套源代碼上工作而擔心。

2020年3月，Brand Finance發布2020年世界500強品牌排行榜，CVS排名第70位。

2020年7月，CVS名列福布斯2020全球品牌價值100強榜第55位。