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:$USER@test.server.address#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:cvs_user_name@cvs.server.address:/path/to/cvsroot login

例子：

cvs -d :pserver:cvs@sam ba.or g:/cvsroot login

不是很安全，因此一般是作為匿名只讀CVS訪問的方式。從安全考慮，通過系統本地賬號認證並通過SSH傳輸是比較好的辦法，通過在客户機的 /etc/profile裏設置一下內容：

CVSROOT=:ext:$USER@cvs.server.address#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:tom@192.168.0.3:/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:$USER@test.server.address#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: 增加

<Directory "/path/to/apache/cgi-bin/cvsweb/">

AuthName "CVS Authorization"

AuthType Basic

AuthUserFile /path/to/cvsweb.passwd

require valid-user

</Directory>

將$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都能方便的跟蹤。

cvs Windows客户端：穩定版本為1.2

ssh Windows客户端

安裝好以上2個軟件以後：

WinCVS客户端的admin==，preference設置

1．在general選單裏

設置CVSROOT：username@192.168.0.123:/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欄輸入：username@ip.address.of.cvs:/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 構成了一個相對完善的跨平台工作組開發版本控制環境。

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