CVS 基礎
cvs 並不是 eclipse 獨有, 而是 eclipse 支持 cvs. cvs 是用於幾個程序員之間共享程序避免沖突的一個工具, 是 C/S 架構.
cvs 是 java 的一個開源項目.
cvs 存儲庫是開發人員存儲要共享代碼文件的地方. ( repository )
存儲庫有兩種模式:
- pessimistic locking(悲觀鎖定) 目前服務器采用這種模式, 即同時只能有1個開發人員修改某個source.
- optimistic locking (樂觀鎖定) 同時可以有多個開發人員一同修改某個source, 提交修改時, 存儲庫會自動合並所有修改.
默認情況下是使用 “樂觀鎖定”, 但是個人覺得還是”悲觀鎖定”好一點. 不會出現矛盾沖突.
eclipse 采用 “樂觀鎖定” ?
每次提交時, cvs都會為每一個文件分配一個版本號, history 管理.
cvs 還支持同一個模塊同時進行多個開發流, 稱為”分支”(branch) 一個模塊中的主開發流稱為”頭”(head), 分支是從主開發流中分出的叉, 例如, 一個分支代表項目的一個測試版, 或者添加到代碼中首次進行測試的某項新功能.
我們服務器沒有使用分支,
1. 首先要創建一個存儲庫, repository. 共享代碼位置
2. 將 eclipse 連接到存儲庫.( 在eclipse中打開 Repository Exploring 視圖-> new-> Repository Location-> add cvs.
這里要輸入 cvs 服務器名稱, 主機名, cvs存儲庫, 提供用戶名和密碼, 等等.
如果你有一個項目想共享, 只需要點這個項目, 右鍵->Team->share project.
commit 的意思, 是提交文件, 即將文件上傳到 CVS 存儲庫中.
update 獲得更新, 即將服務器中的別人更新的內容(別人已經commit), 更新到自己本地文件.
orveride and update, 如果你對某個source進行了修改, 想回退到跟server同步狀態, 則使用這個命令.
blog
團隊開發中的要求
- 提供方法, 能夠協調對源代碼的更改, 並能繼承這些更改
- 團隊提交工作的歷史記錄
cvs 使用分支(branch) 模型來支持彼此獨立而又高度相互依賴的多個工作流程.這些分支是開發團隊用來共享和集成正在進行中的工作的地方. 可以認為分支是一個共享的工作台, 當團隊成員對源代碼進行更改時就更新這個工作台, 這個模型准許從事CVS團隊項目開發的每個人在進行更改時與其他成員共享其工作, 以及在項目進展期間訪問其他成員的工作.
個人理解,
CVS 全稱 current versions system ( 並發版本系統 )
cvs 允許多個開發人員通過一個中心版本控制系統來記錄文件版本, 從而達到保證文件同步的目錄.
cvs 工作原理 copy-modify-merge （拷貝, 修改, 合並) 具體來說: cvs服務器創建一個源代碼庫(cvs repository), 苦力可以存放許多不同的項目源程序, 由管理員統一管理. cvs 客戶端支持不同平台. 在使用cvs任何源代碼庫之前, 開發人員需要將項目文件檢出到本地(check out), 然后 edit, 最后提交文件(check in)到cvs服務器.
cvs Repository
cvs 源代碼庫 指的是cvs 存儲所有修訂版本歷史記錄的地方, 每個項目都有自己的確定的源代碼庫, 注意:創建一個新的Repository需要管理員權限.
eclipse 創建心的 cvs repostority 方法如下:
cvs repository視圖->右鍵new->Repository Location->彈出 Add CVS Repository對話框.
1. Location
Location區描述的是CVS Repository的定位信息，包括主機(Host)與存儲路徑(Repository)。CVS Repository支持local與remote兩種方式。對於本地，主機名為localhost或者127.0.0.1，存儲路徑前綴為 “:local:”。例如，:local:/usr/local/cvsroot表示CVS Repository位於本地/usr/local/cvsroot目錄。其URL的寫法也因操作系統而有所差別。對於Linux，:local:/usr/local/cvsroot等價於/usr/local/cvsroot。對於Windows，:local:c:/src/cvsroot等價於c:\src\cvsroot。
如果服務器在遠端, 以上host可以輸入IP地址, 然后存儲路徑是在這台機器本地的路徑, 例如/home/cvs.
Repository的目錄分為兩部分：$CVSROOT/CVSROOT包含的是CVS的管理文件，而其余部分為用戶自定義模塊。我們除了使用Eclipse CVS客戶端的方式指定Repository之外，還可以通過CVS命令行的方式，如下：
cvs -d /usr/local/cvsroot checkout yoyodyne/tc #–d選項表示direcotry，即CVS Repository對應的目錄。
它等價於：
setenv CVSROOT /usr/local/cvsroot
export CVSROOT
checkout yoyodyne/tc
我們來分析一下CVS Repository對應的數據結構。我們假設當前的CVS Repository為/usr/local/cvsroot，如圖。CVS Repository目錄包含兩部分，一部分為administrative files, 給CVS系統管理員使用，記錄一些Repository相關的元數據等。另一部分就是源代碼目錄結構，這里源代碼項目的根目錄為yoyodyne。
我們服務器, 全部在 cvsroot 目錄下
2. Authentication
authentication 描述認證信息
3. Connection
我們是采用默認方式
Connection區描述的是CVS客戶端與CVS 服務器端的Repository之間的通信協議。當然，CVS客戶端與服務器端可以是同一台機器，此時的主機名為localhost或者 127.0.0.1。按照類型與需求的不同，又分為以下三類協議，分別為：pserver，ext/extssh，pserverssh2。具體含義如 下：
pserver協議：指CVS客戶端向服務器發送的密碼以明文的方式傳送。對於匿名用戶，URL為cvs -d :pserver:fun.example.com:/usr/local/cvsroot; 而對於密碼用戶，按照顯式與隱式划分，URL分別表示為：
cvs -d :pserver:doublelife@fun.example.com:/usr/local/cvsroot login
CVS password:
或者
cvs -d :pserver:doublelife:p4ss30rd@fun.example.com:/usr/local/cvsroot login
注意：cvs –d 命令表示指定CVS Repository。
ext/extssh：指使用SSH建立CVS客戶端/服務器間的安全連接。因此，從應用場景上說，Pserver通常適用於普通用戶或匿名用戶，而對 於要求安全性較高的開發人員，則推薦使用ext/extsssh。ext與extssh的區別在於extssh只支持SSH1，而ext支持SSH1與 SSH2。換句話說，extssh是ext的子集，推薦使用ext。需要說明的是，Eclipse CVS Repository透視圖本身已經內置有SSH客戶端，無需額外的插件。下面是演示的是ext協議對應的CVS命令：
export CVS_RSH=ssh
cvs -d :ext:doublelife:p4ss30rd@fun.example.com:/usr/local/cvsroot
pserverssh2：指的是pserver over SSH2。我們簡單的理解為pserverssh2是SSH2與pserver兩種協議的疊加。相比pserver與ext/extssh來說，並不常用，這里就不給出示例了。
對於CVS客戶端/服務器間的通信協議，除連接類型外，還需要指定服務器端監聽端口。服務器既可以使用默認端口，也可以根據需要，指定端口。比 如，pserver協議對應的默認端口為2401，如果該端口被其他的服務器占用，處於偵聽狀態，此時CVS 服務器可以為Repository指定可用端口。
在完成所有字段的填充后，我們推薦選中“是否在向導完成后驗證連接有效”單選框，確保所填信息完整、有效。
作為示例，我們演示一下使用Eclipse來連接著名開源網站sourceforge的FTP軟件filezilla的CVS Repository，如下圖所示。這里我們采用的是匿名用戶，對應的連接協議為pserver，端口默認值。
如之前所述，CVS Repository為樹狀層級結構。在正式開始copy->modify->merge三部曲之前，有必要花些時間熟悉上圖CVS的幾個關鍵概念：Module，HEAD，Branches，Versions，Dates。
Module
如前所述，CVS Repository分為兩部分，一部分是CVSROOT，描述CVS工程相關的元數據。另一部分即為Module，表示工程的模塊。比如 filezilla分為三大模塊，分別為FileZilla，Filezilla Server，Filezilla3。
Head
簡單的說，HEAD表示CVS代碼的主干與主體部分，正常情況下，我們對CVS的操作三部曲均發生在HEAD目錄中。
Branch
我們沒有使用 Branch
而對於一些特殊的情況，我們采用的Branch方式。Branch相對於HEAD而言，指的是代碼的分支部分，我們簡單的理解為補丁。舉個例子，假設我 們的項目發布了第一個版本V1.0，第二版本V2.0正在開發當中，處於不穩定狀態，隨時有代碼的改動。而與此同時，客戶報告重大的bug，需要我們立即 修復。於是，我們check out V 1.0的代碼，調試，並找到解決辦法，並發布補丁。為了讓補丁與開發代碼隔離，我們可以創建一個新的branch，用於V 1.0的補丁，用戶從branch中check out的是V1.0的補丁，而不會得到位於HEAD目錄的尚在開發階段V2.0代碼。當然根據需要，開發人員可以將branch代碼合並至HEAD中。
為更好地說明問題，我們從版本Revision控制的角度來對比HEAD與Branch的關系。一般說來，HEAD的Revision歷史呈線性增長趨勢，如下圖:
由於Branch概念的介入，使得CVS並不局限於線性的開發，HEAD版本可以分為若干不同的Branch，每一個Branch是一個獨立開發的自我 維護的開發線。如下圖所示，出現了三個不同的分支，分支號的編排依賴於它分離出的主線版本。使用分支號允許一個特定版本分離出多個分支，圖中 Revision 1.2同時派生出兩個不同的Branch。一個分支也允許派生出多個子分子，Branch 1.2.2派生了一個sub branch。
一個Branch的變更可以很容易轉移到HEAD中。可以通過CVS命令update配合-j選項實現合並。這里的-j表示join。
舉個例子，我們當前的HEAD版本為1.4。現在需要將分支1.2.2合並到HEAD。
我們假設模塊”mod”只包含一個文件”mod.c”。分支1.2.2分配了一個名字叫R1fix。
CVS checkout mod #檢出最新版本1.4
CVS update –j R1fix m.c #合並所有分支中的變更，即1.2與1.2.2.2.2的合並
CVS commit –m “Included F1fix” #建立新版本1.5
下圖就是合並后的Revision歷史結構。
在合並過程中可能會發生沖突，可以通過手工地方式解決。
Versions/Tag
我們沒有使用 Versions
Version是標簽Tag的集合。所謂Tag指的是當項目達到某一個milestone時，對所有文件做一個標簽，記錄歷史記錄。通常對一個release做一個tag，如下圖所示。
類似 老李所說的 excel 管理, 有里程碑一樣的修改完成后, 做一個 save as
為更好地理解tag的工作原理，我們可以將 tag 想象成為一條在由文件名和修訂號組成的矩陣上穿過的“曲線”，如下圖所示：
當我們將該 tag 曲線上的 * 標記拉直后，你就得到了由所有 tag 修訂號組成的如下圖的水平線：
由於tag的目的是記錄開發歷史，因此人們通常不會刪除或者改變標簽。對tag的刪除，移動，重命名多半是因為臨時使用標簽或者不小心放錯位置。警告，下列命令會永久刪除歷史信息，使用時應盡量小心。
cvs rtag -d rel-0-4 tc
Dates/Tags
與Versions一樣，Dates也是標簽Tag的集合。區別在於前者以版本作為tag的標記，而后者則以時間為標記。相比與Date類型，Version Tag更加常用。
為了更好的全面理解這些核心CVS概念，我們通過Show History視圖將這些概念串聯起來，如下圖所示。
有對了相關概念的理解，接下來，我們將介紹CVS的常用操作。相信大家對日常的操作如update，commit非常熟悉，只做簡單介紹。更多地是關注那些容易忽視但是特別使用的命令。
作為三部曲之一的Copy操作，CVS對應的命令為check out。具體操作是，選擇HEAD目錄下的目標源文件夾，右鍵單擊Check Out，如圖：
Check Out
Check out之后的本地工作目錄與CVS目錄一致。如果想自定義文件夾的根目錄，則可選擇Check Out As命令。
Switch to another Branch or Version
作為三部曲之二的Modify操作，除正常的源代碼變更操作外，對應一個非常重要的Eclipse CVS命令，即Switch to another Branch or Version，即切換到其它分支或者標簽做源代碼的修改，如圖：
Merge
作為三部曲之三的Merge操作，除正常的update/commit外，也對應的一個非常重要的CVS命令merge，即將branch或tag與HEAD中的Base version進行合並，如圖
Branch
此外，如果想創建一個新的分支，可通過右鍵Team -> Branch打開Create a new CVS Branch。
Tag
如果需要發布一個新的版本2.0.6，可以新創建一個Tag。步驟為右鍵源代碼工程 –> Team -> Tag as
Version，如圖。通過CVS Repository透視圖可以查看相應的Tag。
Patch
補丁(patch)允許開發人員共享尚未提交到CVS的代碼變更。補丁程序包含的是本地資源與CVS資源庫的差別CVS Diff命令。補丁在許多場合都非常有用：
· 由於權限的限制，需要將補丁程序發送給權限用戶提交。
· 需要一個臨時工作區間隔離待提交的代碼。
· 在提交CVS之前，需要對更改的文件測試，可以將補丁程序發送給測試人員。
要創建一個補丁，使用右鍵Team –> Create Patch，開啟Create Patch向導完成補丁文件的創建。
這里我們將補丁程序導出成文件patch.txt。按照默認方式完成向導。patch.txt內容如下：
### Eclipse Workspace Patch 1.0
#P source
Index: AsyncGssSocketLayer.cpp
===================================================================
RCS file: /cvsroot/filezilla/FileZilla/source/AsyncGssSocketLayer.cpp,v
retrieving revision 1.14
diff -u -r1.14 AsyncGssSocketLayer.cpp
--- AsyncGssSocketLayer.cpp 4 Mar 2005 10:35:04 -0000 1.14
+++ AsyncGssSocketLayer.cpp 28 Nov 2011 07:26:39 -0000
@@ -1,6 +1,6 @@
// GSSAsyncSocksifiedSocket.cpp: implementation of the CAsyncGssSocketLayer class.
//
-//////////////////////////////////////////////////////////////////////
+//////////////////////////////////////////////////////////////////////
// Part of this code is copyright 2001 Massachusetts Institute of Technology
#include "stdafx.h"
patch.txt實際上是CVS Diff命令的輸出，從而實現了CVS Repository之外的資源共享。相應地，開發人員可以共享補丁程序。
Apply Patch命令提供了打補丁的方法，如圖所示。
比較&替換
人生沒有后悔葯，但是Eclipse提供了，而且特別簡單。快捷菜單操作Replace With和Compare With提供了本地歷史記錄與CVS Repository比較與替換的機會。需要說明的是，CVS Repository的資源既可以是HEAD也可以來自某一個分支，或者某一個tag。
重命名
一般情況下，要避免對CVS Repository作重命名操作。對於工程而言，CVS對待重命名后的工程為新工程。相應地，需要使用Team -> Disconnect操作解除項目與CVS的關聯，然后再對項目重命名，最后，在重新連接到CVS之后，需要像其它新的工程一樣定義。而對於文件而言，重命名會導致出現一個新的文件，不過幸運的是，原文件的內容會被拷貝到新的文件中。
CVS vs SVN
至此，相信讀者對Eclipse CVS客戶端有一個基本的了解。不過，CVS並非是完美的。下面我們來比較下兩者的一些主要的不同點，如下表。
存儲類型存取速度事務總體評價
CVS文件相比SVN慢沒有實現4
SVN數據庫相比CVS快完全實現5
實際上，CVS是一個古老的系統，其內部結構有許多改進之處。知道今天，仍有人想重頭開始，重寫CVS，但都未能成功，SVN的開發人員花了很多時間與心思在改進內部結構，使其變得簡單、優雅，甚至有人認為SVN是CVS的接班人。
