cvs客戶端大全(轉)

cvs客戶端大全(轉)[@more@]

　　什麼是 CVS？

　　CVS 是一種客戶機／伺服器系統，可以讓開發人員將他們的專案儲存在稱為資源庫的中央位置。使用 cvs 客戶機工具，開發人員可以對資源庫的內容進行更改。CVS 資源庫會依次記錄對每個檔案所做的每個更改，並建立一個完整的專案開發進展歷史。開發人員可以請求特定原始檔的舊版本、檢視更改日誌，並根據需要執行其它一些有用的任務。

　　許多開放軟體專案都有他們自己的 CVS 伺服器，專案開發人員把這些伺服器作為他們工作的原始碼倉庫。原始碼倉庫的原始碼目錄中儲存的都是實現版本控制的歷史檔案(history file)，歷史檔名為filename,v。歷史檔案包含用來恢復所有版本檔案的足夠資訊、所有提交的資訊以及提交者資訊。歷史檔案常常被稱作RCS檔案，因為最早是RCS程式用這種格式來儲存檔案的所有修改資訊，可以從man rcsfile得到歷史檔案的。

　　開發人員每天都會改進 CVS 資源庫內的原始碼，且他們往往分佈在世界各地，而 CVS 提供了一種必要的機制，將他們的專案聯合成一個集中的、協作的整體。CVS 建立了"組織粘和劑"，可以讓這些開發人員改進程式碼而不會干擾別人、丟失重要資料或遺漏彼此對特定原始檔的重要更新。

　　當開發人員準備好以後，他們把 CVS 上部分當前工作打包成 .tar.gz 檔案，作為軟體包的新官方版本來發布它。然而，由於種種原因，最新的官方發行版有時並不是最新的。在本教程的第一部分將首先介紹如何使用CVS為個人使用獲取最新和最高開發人員版本的原始碼。

　　CVSROOT

　　在開始前，您需要了解一些 CVS 的基礎知識。首先，為了連線到 CVS 資源庫，您需要知道稱為 "CVSROOT" 的路徑。CVSROOT 是一個字串，就象 URL，它告訴 cvs 命令遠端資源庫在哪裡，以及如何連線它。不僅如此，根據 CVS 資源庫是本地的還是遠端的，以及連線到它的不同方式，CVS 還有許多不同的 CVSROOT 格式。這裡有一些帶有解釋的 CVSROOT 示例。

　　本地 CVSROOT

CVSROOT=/home/cvsroot

　　這是一個本地 CVSROOT 路徑的示例；如果您想連線到 /home/cvsroot 中存在的本地資源庫，或者有一個經 NFS 安裝在 /home/cvsroot 的資源庫，需要象這樣使用 CSROOOT。

　　遠端密碼伺服器 CVSROOT

CVSROOT=:pserver:cvs@foo.bar.com:/home/cvsroot

　　這裡是一個遠端資源庫的 CVSROOT 示例，該資源庫位於 foo.bar.com 主機上，並在這臺機器的 /home/cvsroot 目錄中活動。前導 ":pserver:" 告訴我們的客戶機使用 CVS 密碼伺服器協議連線到這臺遠端機器，該協議內建在 CVS 中。一般情況下，公共 CVS 資源庫使用密碼伺服器協議以允許匿名使用者訪問。

　　遠端 rsh/ssh CVSROOT

CVSROOT=drobbins@foo.bar.com:/data/cvs

　　這是一個使用 RSH 或 SSH 協議的 CVSROOT 的示例；在該例中，CVS 伺服器嘗試使用 drobbing 帳戶來訪問在 foo.bar.com 上的資源庫。如果 CVS_RSH 的環境變數設定成 "ssh"，那麼我們的客戶機就嘗試用 ssh 去連線；否則就使用 rsh。那些關注安全性的使用者往往使用 ssh 訪問法；但是，無論是 RSH 還是 SSH 方法都不能對匿名使用者提供一種獲取原始碼的方式。為了使用這種方法，您在 foo.bar.com 上必須有個登入帳戶。

　　除了 CVSROOT 之外，您還需要知道要檢出的模組（原始碼集合）的名稱，以及登入到 CVS 密碼伺服器的匿名密碼。與匿名 ftp 不同，匿名密碼沒有什麼"標準"格式，所以您需要從開發人員網站或開發人員那裡獲得具體的密碼。一旦知道了所有這些資訊，就可以開始了。

　　與 CVS 互動

　　獲取原始碼需要兩個步驟。首先，以遠端密碼伺服器的方式登入到CVS伺服器。然後，使用"checkout"命令獲取原始碼。這裡有一組命令的示例，用於檢出最新的 Samba 原始碼（一個流行的 UNIX/Windows 整合專案）：

# export CVSROOT=:pserver:cvs@pserver.samba.org:/cvsroot

　　第一個命令設定 CVSROOT 環境變數。如果沒有設定這個變數，下面兩個命令將需要跟在 "cvs" 命令後再加上 "-d :pserver:cvs@pserver.samba.org:/cvsroot"。設定 CVSROOT 環境變數省去了一些輸入。

# cvs login

(Logging in to cvs@pserver.samba.org)

CVS password：（在此輸入密碼）

# cvs -z5 checkout samba

U samba/COPYING

U samba/Manifest

U samba/README

U samba/Read-Manifest-Now

U samba/Roadmap

U samba/WHATSNEW.txt

（這只是完整的 cvs check 輸出的一小段摘錄）

　　上面第一個 cvs 命令是讓我們登入到 pserver，第二個命令告訴 CVS 客戶機使用 gzip 壓縮級 5 ("-z5") 在慢速連線上加快傳輸速度，來檢出 ("checkout") samba 模組。對於每個在本地建立的新檔案，cvs 都會列印 "U [path]" 表明這個特定的檔案已經在磁碟上更新過了。

　　一旦檢出命令完成，將在包含最新原始碼的當前工作目錄中看到 "samba" 目錄。還會注意到每個子目錄下都有一個"CVS"目錄 -- CVS 在這些目錄中儲存帳戶資訊，可以放心地忽略它們。一旦檢出結束，使用者就無需擔心是否設定了 CVSROOT 環境變數，也無需再在命令列上指定它，因為現在所有額外的 "CVS" 目錄裡都有它的快取。

　　記住 -- 只需要為初始登入和檢出設定 CVSROOT。

　　更新原始碼

　　現在已經有了原始碼，就可以繼續編譯和安裝它們、檢查它們，或者對它們執行任何操作。

　　偶爾，也需要將已檢(checkout)出的源目錄與 CVS 上的當前版本保持同步。為了做到這一點，您無需再次登入到 pserver；cvs 會將您的認證資訊快取到那些 "CVS"帳戶目錄中。首先，進入主檢出目錄（在這裡是 "samba"），然後輸入：

# cvs update -dP

　　如果有任何新檔案，cvs就會在更新每一行的時候輸出 "U [path]" 行。另外，如果本地編譯了原始碼，您有可能會看到許多 "? [path]" 行；cvs 指出這些目標檔案不來自於遠端資源庫。

　　另外，請注意我們用於 "cvs update" 的兩個命令列選項。"-d" 告訴 cvs 建立可能已新增到資源庫的新目錄（預設情況下，這不會發生），"-P" 告訴 cvs 從本地已檢出的原始碼副本中除去所有空目錄。"-P" 是個不錯的選擇，因為 cvs 傾向於收集許多隨時間產生的空（曾經使用過，但現在已經放棄）目錄樹。

　　如果只是要獲得最新的原始碼，這些就是您所需要了解的。現在，來看一下作為一個開發人員如何與 CVS 互動。

　　修改檔案

　　作為一名開發人員，您需要修改 CVS 上的檔案。要修改檔案，只需要對資源庫的本地副本進行適當的更改。在您明確地告訴 cvs "提交"更改之前，您對原始碼做的更改不會應用到遠端資源庫。測試過所有修改以確保它們可以正常運作之後，就可以準備將這些更改運用到資源庫中，遵循下面的兩個步驟。首先，在主原始碼目錄中輸入以下命令來更新原始碼：

# cvs update -dP

　　CVS 合併其他人的更改

　　我們在前面已經看到，"cvs update"將用資源庫中的當前版本使您的原始碼保持最新狀態 -- 但對您已經做過的更改會發生什麼情況呢？不要擔心，它們不會被丟棄。如果另一個開發人員對您沒動過的檔案做了一些更改，您的本地檔案將進行更新以使它與資源庫中的版本保持同步。

　　如果您修改了本地檔案中的第 1-10 行，而另一個開發人員刪除了第 40-50 行，在檔案末尾新增了 12 行新行，同時修改了 30-40 行，然後在您之前他向資源庫提交了他的更改，cvs 會智慧地將這些更改合併到您本地已修改的副本中，這樣你們的更改就都不會丟失。這可以讓兩個或更多開發人員針對同一檔案的不同部分同時操作。

　　然而，如果兩個或多個開發人員更改同一檔案的同一部分，那麼事情就有些複雜了。如果發生這種情況，cvs 會告訴您有衝突發生。所做的工作不會丟失，但需要手工干預，因為 cvs 需要您提供意見來決定如何合併這些有衝突的更改。

　　提交

　　我們過一會兒來看看衝突究竟是如何解決的，但現在，先讓我們假設在輸入 "cvs update -dP" 後沒有衝突 -- 通常都沒有衝突。由於沒有衝突，本地原始碼是最新的。可以在主原始碼目錄中輸入以下命令來提交對資源庫的更改：

# cvs commit

　　提交所起的作用

　　"cvs commit" 不只將您的更改應用到資源庫。在真正將您的更改提交給遠端資源庫之前，cvs 會呼叫預設編輯器，可以讓您輸入修改的描述。輸入了註解後，儲存該檔案，退出編輯器，您的更改（和註解）就會應用到遠端資源庫，小組中的其他開發人員可以看到這些更改。

　　檢視日誌

　　要檢視某個特定檔案完整的歷史以及提交時開發人員（包括您）所加的註解是很容易的。要檢視這些資訊，輸入：

# cvs log myfile.c

　　"cvs log" 命令是遞迴的，所以如果您想檢視整個目錄樹的完整日誌，只需要進入該目錄，輸入：

# cvs log | less

　　提交選項

　　您可能想要使用另一個輸入 "cvs commit" 時 cvs 在預設情況下啟動的編輯器。如果是這樣，只需要把您希望使用的編輯器的名稱放進 EDITOR 環境變數中。另外，也可以將更新日誌訊息作為命令列選項指定，這樣， cvs 就不需要一上來就裝入編輯器：

# cvs commit -m 'I fixed a few silly bugs in portage.py'

　　.cvsrc 檔案

　　在繼續瞭解其它 cvs 命令前，建議設定 ~/.cvsrc 檔案。透過在您主目錄中建立 .cvsrc 檔案，可以告訴 cvs 在預設情況下使用您所需的命令列選項，這樣就不必每次都輸入它們。這裡有一個推薦的預設 .cvsrc 檔案：

cvs -q

diff -u -b -B

checkout -P

update -d -P

　　除了為一組 cvs 命令設定有用的選項以外，.cvsrc 的第一行將 cvs 置於安靜模式下，它的主要好處是使 "cvs update" 輸出更簡潔，更具可讀性。另外，一旦完成 .cvsrc 後，就可以輸入 "cvs update" 而不是 "cvs update -dP"。

　　將檔案新增到資源庫

　　要將原始檔新增到 CVS 很容易。首先，用您喜愛的文字編輯器建立該檔案。然後，輸入以下命令：

# cvs add myfile.c

cvs server: use 'cvs commit' to add this file permanently

　　這將告訴 cvs 在您下次執行 "cvs commit" 時，將該檔案新增到資源庫。在那之前，其它開發人員看不它。

　　將目錄新增到資源庫

　　將目錄新增到 CVS 的過程類似於：

# mkdir foo

# cvs add foo

Directory /home/cvsroot/mycode/foo added to the repository

　　與新增檔案不同，當您新增目錄時，它會立即出現在資源庫中；不需要 cvs commit。將本地目錄新增到 cvs 後，您會注意到在遠端cvs伺服器的對應目錄中建立了一個 "CVS" 目錄，它作為包含 cvs 帳戶資料的容器。因而，您只要看一下其中是否有 "CVS" 目錄，就可以很容易地知道某個目錄是否已新增到遠端cvs伺服器的 cvs中了

　　在將檔案或目錄新增到資源庫之前，您必須確保它的父目錄已經新增到 CVS。否則，您會看到類似於下面的錯誤：

# cvs add myfile.c cvs add: cannot open CVS/Entries for

reading: No such file or directory cvs [add aborted]: no repository

　　熟悉 "cvs update"

　　在瞭解如何解決衝突之前，先讓我們熟悉一下 "cvs update" 命令的輸出。如果建立了一個包含 "cvs -q" 行的 ~/.cvsrc 檔案，您會發現 "cvs update" 的輸出相當容易理解。"cvs update" 透過列印單個字元、空格和檔名告訴您它都做些什麼，看到些什麼；如下例所示：

# cvs update -dP

? distfiles

? packages

? profiles

　　"cvs update" 用 "?" 字元指示在地副本中找到的這些特殊檔案。它們不是資源庫的正式部分，也不是計劃要新增的部分。這裡有一個CVS使用的所有其它單字元資訊性訊息的列表：

　　U [path]

　　在本地資源庫中建立新檔案，或者更新了您沒有動過的檔案時使用。

　　A [path]

　　該檔案是計劃要新增的，使用 "cvs commit" 時，它被正式新增到資源庫。

　　R [path]

　　象 "A" 一樣，"R" 讓您知道該檔案計劃要除去。輸入 "cvs commit" 後，該檔案就會從資源庫中除去。

　　M [path]

　　這意味著您已經修改過該檔案了；而且，有可能資源庫中新的更改已成功地合併到該檔案。

　　C [path]

　　"C" 字元表明該檔案存在衝突，需要在使用 "cvs commit" 提交更改前手工修改它。

　　如何解決衝突

　　現在，讓我們看一下如何解決衝突。我參與了大部分的 Gentoo Linux 專案，我們在 cvs.gentoo.org 上設定了自己的 cvs 伺服器。我們這些開發人員花了絕大部分時間來修改 "gentoo-x86" 模組內部的原始碼。在 gentoo-x86 模組中，有一個叫 "ChangeLog" 的檔案，它包含了（您猜一下它）我們對資源庫中該檔案做的主要更改的描述。

　　衝突的示例

　　因為幾乎每次開發人員對 CVS 進行主要更改時都會對該檔案做一些修改，這就成為衝突的主要根源 -- 這裡有衝突的一個示例。假設我在 ChangeLog 的頂部新增了以下行：

date 25 Feb 2001

This is the thing I added myself

　　然而，在我提交這二新行之前，另一個開發人員也在 ChangeLog 的頂部新增了這些行並提交了他的更改：

date 25 Feb 2001

This is the part added by another developer

　　現在，當我執行 "cvs update -dP" （每次提交前您都應該這麼做），cvs 不能把他的更改合併到我的 ChangeLog 本地副本，因為我們倆都向檔案的同一部分新增了行 -- cvs 怎麼知道用哪個版本？所以，CVS 會出現以下錯誤：

RCS file: /home/cvsroot/gentoo-x86/ChangeLog,v

retrieving revision 1.362

retrieving revision 1.363

Merging differences between 1.362 and 1.363 into ChangeLog

rcsmerge: warning: conflicts during merge

cvs server: conflicts found in ChangeLog

C ChangeLog

　　啊 -- 有衝突！幸好消除這些衝突很容易。如果我啟動我喜愛的文字編輯器，將會在 ChangeLog 檔案的頂部看到以下文字：

<<<<<<< ChangeLog

date 25 Feb 2001

This is the thing I added myself

=======

date 25 Feb 2001

This is the part added by another developer

>>>>>>> 1.363

　　cvs 不是選其中一個而捨棄另一個，而是把兩個版本都加進 ChangeLog 檔案，並用特殊的分隔符將它們圈起，以明確地標記出有問題的衝突。現在，我要用一個應該出現在 ChangeLog 裡的文字來替換這部分；在這種情況下，替換的文字既不是我的版本也不是他的版本，而是兩者的組合：

date 25 Feb 2001

This is the thing I added myself

This is the part added by another developer

　　我用適當的文字替換掉了有衝突的部分（併除去了 "=======" 等標記），可以順利地將我的更改提交給 cvs。

　　無論什麼時候需要編輯檔案來解決衝突時，都要確保已經瀏覽過整個檔案，以便您知道所有內容；如果您忘記解決某個衝突，那麼在這個衝突解決之前，cvs 是不允許您提交的！很顯然，除去 cvs 新增到衝突檔案中的特殊標記是很重要的。

　　如果您在解決某個衝突時犯了錯誤，然後意外地儲存了您所作的更改，那麼您可以在 ".#filename.version" 檔案中找到您的原始副本。

　　刪除檔案

　　現在應該學習關於 CVS 的最後一個技巧 -- 從資源庫中除去檔案。除去檔案是一個兩階段過程。首先，從原始碼的本地副本刪除該檔案，然後執行相應的 "cvs remove" 命令：

# rm myoldfile.c

# cvs remove myoldfile.c

　　在您下次提交時，該檔案計劃將從資源庫中除去。一旦提交，該檔案會從資源庫當前的版本中正式刪除。然而， cvs 不會將該檔案拋棄，而是仍然完整地保留該檔案的內容及其歷史，以備您以後需要它。這只是 cvs 保護您有價值的原始碼的眾多方法之一。

　　"cvs remove" 是遞迴的，這意味著您可以刪除一批檔案，然後從父目錄執行不帶其它自變數的 "cvs remove" 命令。這樣做會在下次提交時標記所有已刪除的檔案。

　　如果您想除去整個目錄，我推薦使用下列過程。首先，從物理上刪除，"cvs remove" 刪除目錄中的所有檔案：

# rm *.c

# cvs remove

　　然後執行提交：

# cvs commit

　　這裡有一個訣竅。執行以下步驟刪除目錄：

# cd ..

# cvs remove mydir

# rm -rf mydir

　　請注意，除去目錄不需要另一次提交 -- 把目錄新增到資源庫和從資源庫除去目錄是實時的。

　　修訂號

　　原始碼倉庫中的一個檔案可以有多個版本，同樣一個軟體可能有多個版本。一般在CVS中前一種意義上的版本（原始碼倉庫中檔案的版本）一般稱為修訂號(revisions)，而對軟體的版本一般稱為釋出(release)。

　　一個檔案的修訂號一般是依次遞增的，一般以偶數個透過"."連線的十進位制數串來表示，如：`1.1', `1.2', `1.3.2.2'甚至`1.3.2.2.4.5

　　標籤的定義和使用

　　原始碼倉庫中各個檔案的修訂號是獨立增加的，相互之間沒有任何關聯關係，和軟體的釋出號也沒有任何關係，例如一個專案中的各個檔案的修訂號可能是這樣的：

ci.c 5.21

co.c 5.9

ident.c 5.3

rcs.c 5.12

rcsbase.h 5.11

rcsdiff.c 5.10

rcsedit.c 5.11

rcsfcmp.c 5.9

rcsgen.c 5.10

rcslex.c 5.11

rcsmap.c 5.2

rcsutil.c 5.10

　　為了便於標記，可以使用標籤來為某個特定版本的特定檔案設定一個標記以方便訪問，可以使用cvs tag和cvs rtag來定義標籤，其中cvs tag用來為倉庫中當前工作檔案(或檔案集合)指定一個符號標記；cvs rtag用來顯式地為原始碼倉庫的特定修訂號的檔案定義一個標記。例如下面的例子就是給檔案backend.c的當前修訂號定義一個標籤，然後察看該檔案的狀態：

$ cvs tag rel-0-4 backend.c

T backend.c

$ cvs status -v backend.c

===========================================================

File: backend.c Status: Up-to-date

Version: 1.4 Tue Dec 1 14:39:01 1992

RCS Version: 1.4 /u/cvsroot/yoyodyne/tc/backend.c,v

Sticky Tag: (none)

Sticky Date: (none)

Sticky Options: (none)

Existing Tags:

rel-0-4 (revision: 1.4)

　　但是在實際應用中很少會為特定檔案定義一個標籤，而往往是在開發過程中的特定階段為特定專案的所有檔案定義一個標籤，以方便釋出或者定義分支，例如：

$ cvs tag rel-1-0 .

cvs tag: Tagging .

T Makefile

T backend.c

T driver.c

T frontend.c

T parser.c

　　定義標籤以後，可以在隨後的任何時候訪問對應該標籤的專案檔案，例如下面這個命令就用來實現檢出對應於標籤rel-1-0的所有檔案(可能是軟體的1.0釋出)：

$ cvs checkout -r rel-1-0 tc

　　可以想像標籤為聯絡特定修訂號檔案的曲線索引，例如：

　　這裡表示在軟體開發過程中的定義了標籤*，也可這樣看待標籤：

　　當然也可以刪除標籤，例如：

　　cvs rtag(/tag) -d rel-0-4 tc 刪除模組tc的rel-0-4標記

　　備份原始碼倉庫

　　備份： 首先斷開所有的cvs連線，然後使用cp命令備份即可

　　分支

　　透過CVS可以實現將對原始碼的修改提交給一個獨立的開發線，被稱為分支(branch)。當對分支的檔案進行修改時，這些修改不會對主分支和其他分支產生影響。

　　隨後可以將將一個分支的修改合併(merging)到其他分支。合併是透過cvs update -j來合併修改到當前工作目錄(本地)，然後就可以提交修改來影響其他分支了。

　　分支的重要性

　　讓我們假設這種情況，專案tc的1.0版本已經搞定，你將繼續開發tc專案，計劃在幾個月內釋出1.1版本，但是客戶抱怨軟體中有致命的錯誤。因此你檢出1.0版本(這裡就是需要使用標記的原因)並發現了這個bug的原因。然而當前的原始碼處於1.0和1.1版本之間因此程式碼處於混亂狀態，而且在一個月內不大可能出現穩定版本，因此不大可能根據當前的版本得到一個修復錯誤的版本來發布。

　　對於這種情況這就需要建立一個包含錯誤修改的1.0分支釋出，而不需要影響當前的開發，在合適的時候可以將修正合併的主釋出中去。

　　建立分支

　　建立分支首先為擬修改的某些檔案建立一個標籤(tag)，標籤是賦於一個檔案或一組檔案的符號.在原始碼的生命週期裡，組成一組模組的檔案被賦於相同的標籤。

　　建立標籤：在工作目錄裡執行cvs tag 。

　　例: 為src建立標籤：

　　cvs checkout src(/update亦可，用來更新本地的原始碼)

　　cvs tag release-1-0(為當前最新原始碼加一個標籤)

　　標籤建立後, 就可以為其建立一個分支：

　　cvs rtag -b -r release-1-0 release-1-0-path print

　　-b :建立分支

　　-r release-1-0：-r引數用來標記那些包含指定的標籤的檔案

　　releas-1-0-patch:分支

　　print: 模組名

　　可以使用tag -b來建立分支，例如在工作目錄中：

$ cvs tag -b rel-1-0-patches

　　將會基於當前工作的分支分離一個分支，並將該分支命名為`rel-1-0-patches'。應該理解分支是在cvs的原始碼倉庫中建立的，而不是當前工作目錄，基於當前修正建立分支不會將當前工作複製自動轉換為新的分支，需要手工來實現的。也可以透過使用rtag命令實現不涉及工作目錄的分支：

$ cvs rtag -b -r rel-1-0 rel-1-0-patches tc

　　`-r rel-1-0'指示建立的新分支應該以標記`rel-1-0'指定的修訂為基礎，而不是基於當前的工作主分支。這主要是用來從舊版本中建立一個分支(例如上面的例子)。

　　rtag -b指示建立分支(而不是僅僅建立標記)。應該注意的是`rel-1-0'包含的各個檔案的修訂號可能是不一樣的。

　　所以該命令的效果是為工程tc建立一個新分支-名字為`rel-1-0-patches'，以標記`rel-1-0'為基礎。

　　訪問分支

　　可以以兩種方式訪問分支：從原始碼倉庫中檢出分支程式碼，或者將當前的工作複製切換為分支。

　　從原始碼倉庫中創檢出新分支可以使用命令'checkout -r release-tag'命令：

$ cvs checkout -r rel-1-0-patches tc

　　將當前分支切換到分支命令：

$ cvs update -r rel-1-0-patches tc

　　或者

$ cd tc

$ cvs update -r rel-1-0-patches

　　隨後的提交等影響原始碼倉庫的操作都僅僅對分支起作用，而不會影響主分支和其他分支。可以使用status命令來察看當前工作複製屬於哪個分支。輸出中察看'sticky tag'資訊，這就是cvs顯示當前工作複製是在哪個分支上：

$ cvs status -v driver.c backend.c

=============================================================

File: driver.c Status: Up-to-date

Version: 1.7 Sat Dec 5 18:25:54 1992

RCS Version: 1.7 /u/cvsroot/yoyodyne/tc/driver.c,v

Sticky Tag: rel-1-0-patches (branch: 1.7.2)

Sticky Date: (none)

Sticky Options: (none)

Existing Tags:

rel-1-0-patches (branch: 1.7.2)

rel-1-0 (revision: 1.7)

=============================================================

File: backend.c Status: Up-to-date

Version: 1.4 Tue Dec 1 14:39:01 1992

RCS Version: 1.4 /u/cvsroot/yoyodyne/tc/backend.c,v

Sticky Tag: rel-1-0-patches (branch: 1.4.2)

Sticky Date: (none)

Sticky Options: (none)

Existing Tags:

rel-1-0-patches (branch: 1.4.2)

rel-1-0 (revision: 1.4)

rel-0-4 (revision: 1.4)

　　不要被每個檔案的分支號碼不同(`1.7.2'和`1.4.2')所迷惑，分支是由分支標記來決定的這裡都是' rel-1-0-patches'。這裡的分支號僅僅表示當生成該分支時每個檔案的修訂號。

　　分支和修訂號

　　通常情況下原始碼庫中檔案的修訂號是以線性增大的:

　　+-----+ +-----+ +-----+ +-----+ +-----+

　　! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 !

　　+-----+ +-----+ +-----+ +-----+ +-----+

　　但是CVS並不侷限於線性開發，原始碼樹可能出現分支，每個分支是一個對立的開發線。對分支的修改會很容易地被加入到主分支中來。

　　每個分支都擁有一個分支號，由使用"."分隔的奇數個陣列成的數串來表示。分支號是透過在產生分支處的修訂號後新增一個整數來實現得到的。透過定義分支號使得從同一個分支點分出多個開發分支成為可能。

　　分支的修訂號是透過在分支號後順序新增數字字尾得到的，如下圖所示：

　　分支號產生的詳細細節其實是不必詳細瞭解的，但是瞭解其工作原理是必要的：當CVS建立一個分支時，其選擇一個最小的偶數作為分支號字尾。因此當希望從修訂號6.4分出一個分支時，新分支的分支號為6.4.2。所有以0作為分支號字尾的分支號都被CVS自己保留使用(例如6.4.0)。

　　合併分支

　　分支開發一段時間以後往往需要將修訂合併到主分支中來，可以透過`-j branchname'引數實現合併分支。使用該引數將分支和其父分支合併。

　　考慮下面的原始碼修訂樹：

　　分支1.2.2被定義為標記R1fix。下面的例子假設模組mod僅僅包含一個檔案m.c:

　　$ cvs checkout mod #獲取最新的1.4版本

　　$ cvs update -j R1fix m.c # 合併分支的所有更新到主分支

　　# 也就是1.2到1.2.2.2的修改合併到當前工作複製

　　$ cvs commit -m "Included R1fix" # 建立修訂版本1.5.

　　合併時可能出現衝突情況，如果發生衝突，應該在提交以前手工處理衝突。

　　檢出命令(checkout)命令同樣支援引數 `-j branchname'，上面的操作可以透過下面的命令實現；

$ cvs checkout -j R1fix mod

$ cvs commit -m "Included R1fix"

　　一個需要注意的問題是"update -j tagname"同樣能

　　參考資料：