CVS使用手册
CVS使用手冊
作者：車東 發表于：2002-02-06 18:02 最后更新于：2008-02-15 22:02
版權聲明：可以任意轉載，轉載時請務必以超鏈接形式標明文章原始出處和作者信息及本聲明。
http://www.chedong.com/tech/cvs_card.html
CVS是一個C/S系統，多個開發人員通過一個中心版本控制系統來記錄文件版本，從而達到保證文件同步的目的。工作模式如下：
?????? CVS服務器（文件版本庫）
???? /???? |?????? \
???? （版本同步）
?? /?????? |???????? \
開發者1? 開發者2?? 開發者3
作為一般開發人員挑選2,6看就可以了，CVS的管理員則更需要懂的更多一些，最后還簡單介紹了一些Windows下的cvs客戶端使用，CVS遠程用戶認證的選擇及與BUG跟蹤系統等開發環境的集成問題。
1. CVS環境初始化：CVS環境的搭建管理員
2. CVS的日常使用：日常開發中最常用的CVS命令，開發人員管理員
3. CVS的分支開發：項目按照不同進度和目標并發進行管理員
4. CVS的用戶認證：通過SSH的遠程用戶認證，安全，簡單管理員
5. CVSWEB：CVS的WEB訪問界面大大提高代碼版本比較的效率管理員
6. CVS TAG：將$Id$ 加入代碼注釋中，方便開發過程的跟蹤開發人員
7. CVS vs VSS: CVS和Virsual SourceSafe的比較開發人員管理員
8. WinCVS:通過SSH認證的WinCVS認證設置
9. 基于CVSTrac的小組開發環境搭建：通過CVSTrac實現web界面的CVS用戶管理,集成的BUG跟蹤和WIKI交流
10.?? CVS中的用戶權限管理：基于系統用戶的CVS權限管理和基于CVSROOT/passwd的虛擬用戶管理
一個系統20%的功能往往能夠滿足80%的需求，CVS也不例外，以下是CVS最常用的功能，可能還不到它全部命令選項的20%，作為一般開發人員平時會用cvs update和cvs commit就夠了，更多的需求在實際應用過程中自然會出現，不時回頭看看相關文檔經常有意外的收獲。
CVS環境初始化
環境設置：指定CVS庫的路徑CVSROOT
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的日常使用
?
注意：第一次導出以后，就不是通過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 "bug fixed" 甚至 -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.name
這個命令是給file.name加一個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
CVS 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的遠程認證通過SSH遠程訪問CVS
使用cvs本身基于pserver的遠程認證很麻煩,需要定義服務器和用戶組，用戶名，設置密碼等，
常見的登陸格式如下：
cvs -d :pserver:cvs_user_name@cvs.server.address:/path/to/cvsroot login
例子：
cvs -d :pserver:cvs@samba.org:/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：提高文件瀏覽效率
CVSWEB就是CVS的WEB界面，可以大大提高程序員定位修改的效率:
使用的樣例可以看：http://www.freebsd.org/cgi/cvsweb.cgi
CVSWEB的下載：CVSWEB從最初的版本已經演化出很多功能界面更豐富的版本，這個是我個人感覺安裝設置比較方便的：
原先在：http://www.spaghetti-code.de/software/linux/cvsweb/，但目前已經刪除，目前仍可以在本站下載CVSWEB，其實最近2年FreeBSD的CVSWeb項目已經有了更好的發展吧，而當初沒有用FreeBSD那個版本主要就是因為沒有彩色的文件Diff功能。
下載解包：
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：
1. 修改CVSROOT路徑設置：
%CVSROOT = (
'Development' => '/path/to/cvsroot', #<==修改指向本地的CVSROOT
);
2. 缺省不顯示已經刪除的文檔：
"hideattic" => "1",#<==缺省不顯示已經刪除的文檔
3. 在配置文件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>
CVS TAGS: $Id$
將$Id$ 加在程序文件開頭的注釋里是一個很好的習慣，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$
?*/
?>
====================================
Default.java: 注意文件頭一般注釋用 /* 開始 JAVADOC注釋用 /** 開始的區別
/*
?* Copyright (c) 2002 MyCompany Name.
?* $Header$
?*/
package com.mycompany;
import java.;
/**
?* comments here
?*/
public class Default {
??? /**
???? * Comments here
???? * @param
???? * @return
???? */
??? public toString() {
??? }
}
====================================
default.pl:
#!/usr/bin/perl -w
# Copyright (c) 2002 Company Name.
# $Header$
# file comments here
use strict;
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$ $Date$這樣的標記在Virsual SourceSafe中稱之為Keyword Explaination，缺省是關閉的，需要通過OPITION打開，并指定需要進行源文件關鍵詞掃描的文件類型：*.txt,*.java, *.html...
對于Virsual SourceSafe和CVS都通用的TAG有：
$Header$
$Author$
$Date$
$Revision$
我建議盡量使用通用的關鍵詞保證代碼在CVS和VSS都能方便的跟蹤。
WinCVS
下載：
cvs Windows客戶端：目前穩定版本為1.2
http://cvsgui.sourceforge.net
ssh Windows客戶端
http://www.networksimplicity.com/openssh/
安裝好以上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
下載：
http://www.prestosoft.com/examdiff/examdiff.htm
還是在WinCVS菜單admin==>preference的WinCVS選單里
選上：Externel diff program
并設置diff工具的路徑，比如：C:\Program Files\ed16i\ExamDiff.exe
在對文件進行版本diff時，第一次需要將窗口右下角的use externel diff選上。
基于CVSTrac的小組開發環境搭建
作為一個小組級的開發環境，版本控制系統和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有讀取權限。
?
安裝過程
1. 下載：可以從http://www.cvstrac.org下載
我用的是已經在Linux上編譯好的應用程序包：cvstrac-1.1.2.bin.gz，
%gzip -d cvstrac-1.1.2.bin.gz
%chmod +x cvstrac-1.1.2.bin
#mv cvstarc-1.1.1.bin /usr/bin/cvstrac
如果是從源代碼編譯：
從 http://www.sqlite.org/download.html 下載SQLITE的rpm包：
rpm -i sqlite-devel-2.8.6-1.i386.rpm
從 ftp://ftp.cvstrac.org/cvstrac/ 下載軟件包
解包，假設解包到/home/chedong/cvstrac-1.1.2下，并規劃將cvstrac安裝到/usr/local/bin目錄下， cd /home/chedong/cvstrac-1.1.2 編輯linux-gcc.mk:
修改：
SRCDIR = /home/chedong/cvstrac-1.1.2
INSTALLDIR = /usr/local/bin
然后
mv linux-gcc.mk Makefile
make
#make install
2. 初始化cvstrac數據庫：假設數據庫名是 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 apache
Group apache，
然后設置屬于apache用戶和apache組
#chown -R apache:apache /home/cvsroot
-rw-r--r-- 1 apache apache 55296 Jan 5 19:40 myproj.db
drwxrwxr-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
3. 在apche/cgi-bin目錄中創建腳本cvstrac:
#!/bin/sh
/usr/bin/cvstrac cgi /home/cvsroot
設置腳本可執行：
chmod +x /home/apache/cgi-bin/cvstrac
4. 從 http://cvs.server.address/cgi-bin/cvstrac/myproj 進入管理界面
缺省登錄名：setup 密碼 setup
對于一般用戶可以從：
http://cvs.server.address/cgi-bin/cvstrac/myproj
5. 在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的用戶權限管理
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 構成了一個相對完善的跨平臺工作組開發版本控制環境。
相關資源：
CVS HOME：
http://www.cvshome.org
CVS FAQ：
http://www.loria.fr/~molli/cvs-index.html
相關網站:
http://directory.google.com/Top/Computers/Software/Configuration_Management/Tools/Concurrent_Versions_System/
CVS--并行版本系統
http://www.soforge.com/cvsdoc/zh_CN/book1.html
CVS 免費書:
http://cvsbook.red-bean.com/
CVS命令的速查卡片 refcards.com/refcards/cvs/
WinCVS:
http://cvsgui.sourceforge.net/
CVSTrac: A Web-Based Bug And Patch-Set Tracking System For CVS
http://www.cvstrac.org
StatCVS：基于CVS的代碼統計工具：按代碼量，按開發者的統計表等
http://sourceforge.net/projects/statcvs
如何在WEB開發中規劃CVS上：在Google上查 "cvs web development"
http://ccm.redhat.com/bboard-archive/cvs_for_web_development/index.html
一些集成了CVS的IDE環境：
Eclipse
- Eclipse, CVS使用指南（轉）
版權聲明：轉載時請以超鏈接形式標明文章原始出處和作者信息及本聲明
http://hrbyzq.blogbus.com/logs/20754969.html
本文概述了 Eclipse 平臺如何支持軟件項目中的源代碼版本控制。首先，我們將簡要討論一下團隊代碼開發的思想，然后研究 Eclipse 如何使用 CVS 代碼資源庫。我們還將研究一些源代碼管理軟件工具，可以通過 Eclipse 插件擴展來支持這些工具。
在團隊項目中共享源代碼
現今的大多數應用程序是由多人組成的團隊開發的。即使只涉及幾個開發人員的小項目，也需要對源代碼的更改進行嚴格控制。這就是源代碼管理軟件的任務。源代碼版本控制軟件必須支持兩個核心功能：
提供一種方法，能夠協調對源代碼的更改，并能集成這些更改
團隊所提交工作的歷史記錄
當團隊成員完成新的工作時，通過將這些更改提交到資源庫來共享他們的工作。類似地，當他們希望獲得最新可用的工作成果時，就可以根據資源庫中的更改，更新自己的本地工作空間。這意味著項目資源庫會因團隊成員提交新工作成果而經常發生更改。換句話說，資源庫應該表示項目的當前狀態。任何時候，團隊成員都要能夠根據資源庫更新自己的工作空間，并確信它們是最新的。
維護歷史記錄也很重要，那樣就可以將當前工作與先前版本進行比較，如有必要，還可以回復到先前版本。協調團隊的工作，以便只存在唯一的當前項目狀態定義，以及包含團隊已集成的工作，這些對于管理版本控制也是十分必要的。這種協調有可能是最難實現的目標。
最理想的模型是：團隊的任何成員都可以對自己有權訪問的任何資源進行更改。因為兩個團隊成員可以提交對同一資源的更改，所以有可能發生沖突，必須解決這種沖突。這種模型假定沖突具有唯一性。但遺憾的是，沒有任何源代碼是孤立地存在的；通常它包含與其它資源隱式或顯式的相關性。源代碼引用了在其它源代碼資源中描述的構件。但源代碼管理軟件的工作就到此為止了，因為它并不能取代項目管理。項目管理者必須履行其職責：協調其它成員的工作以及負責進度、項目階段和發布日期。此外，源代碼管理也不能替代開發人員之間的交流。
Eclipse 平臺如何支持代碼管理
Eclipse 平臺提供了作為團隊在軟件項目中共享代碼和工作的能力。Eclipse 廣泛地支持各種代碼管理解決方案，這要歸功于它的插件體系結構（不過，現已推出了對 CVS 的支持）。Eclipse 平臺體系結構的重點在于工作空間。工作空間維護構建和測試軟件項目所需的一切。它包含對象（源代碼和資源）。它還保存了用于項目、IDE 和插件的配置設置。工作空間是在開發人員的機器上本地進行維護的，而團隊通過外部資源庫進行協作，不同開發人員的代碼在資源庫進行匯集。可以經由因特網通過“客戶機-服務器”體系結構訪問資源庫。
Eclipse 平臺提供了對于直接從工作空間進行團隊開發操作的支持。這種支持允許開發人員并發地與幾個獨立的資源庫以及不同版本的代碼或項目進行交互。工作空間中的資源允許團隊支持組件處理版本和配置管理問題。當然，單個工作空間可以同時訪問不同類型的資源庫。Eclipse 平臺并沒有提供它自己的代碼管理解決方案；它總是依靠外部系統。Eclipse 平臺只對一個（但也是最流行的一個）源代碼管理系統提供內置支持：并發版本控制系統（Concurrent Versions System，CVS）。對第三方代碼管理應用程序的支持一節中描述了使用第三方插件支持其它資源庫。
CVS 是什么？
CVS 誕生于 1986 年，當時作為一組 shell 腳本而出現，但它現在已經發展成了最流行的針對軟件開發人員的源代碼版本管理解決方案。CVS 是用于代碼版本管理的開放源碼的客戶機／服務器解決方案，它可用于各種平臺，包括 Linux 和 Windows NT/2000/XP。請參閱本文末尾的參考資料，其中有 CVS 客戶機、服務器和源代碼的下載鏈接。
通常，CVS 的主要功能是記錄源文件的歷史。當一組開發人員從事同一個項目時，CVS 將他們彼此隔離開來。每個開發人員都在他／她自己的目錄中獨立工作，然后使用 CVS 資源庫（不時地）合并工作結果。
Eclipse 擁有與 Eclipse 平臺 IDE 緊密集成的內置 CVS 客戶機，它是作為一個單獨透視圖（CVS Repository Exploring 透視圖）而實現的，用于與 CVS 的交互。用于 CVS 的通用 Eclipse 設置（General Eclipse settings for CVS）位于 Window -> Preferences window -> Team 下。在切換到 CVS Repository Exploring 透視圖之后，就可以使用所有 CVS 操作了（轉至 Window -> Open Perspective -> Other -> CVS Repository Exploring。
先設置資源庫的位置，它將定義用于選定 CVS 服務器／資源庫的連接參數。
Eclipse/CVS 的源代碼工作流
在 CVS 團隊協作模型中，團隊成員彼此獨立地在他們各自的工作臺上完成自己的所有工作。最后，他們希望共享其工作。他們通過 CVS 資源庫實現這一點。CVS 使用分支（branch）模型來支持彼此獨立而又高度相互依賴的多個工作流程（course of work）。這些分支是開發團隊用來共享和集成正在進行中的工作的地方。可以認為分支是一個共享的工作臺，當團隊成員對源代碼進行更改時就更新這個工作臺。這個模型允許從事 CVS 團隊項目的每個開發人員在進行更改時與其他成員共享其工作，以及在項目進展期間訪問其他成員的工作。
一個稱為 HEAD 的特殊分支用來表示資源庫中的主要工作流程（HEAD 通常被稱為主干）。當團隊成員將資源提交給該分支時，會影響這些相關性。確保相關性的完整性是很重要的，因為該分支表示了當前項目的狀態。當然，任何時候，團隊成員都可以使用該分支的內容作為新工作的基礎。
那些規則不僅適用于 CVS：無論使用哪種版本控制軟件，團隊項目中都有一些用于源代碼管理的常見步驟。下面是一個使用 Eclipse 內置的 CVS 支持的示例工作流：
1. 啟動新的團隊項目
每個新的空 Eclipse 項目都可以通過 CVS（或受支持的任何其它源代碼管理系統）進行共享。開發人員也可以通過將其現有的代碼遷移到資源庫來共享它。要進行共享，單擊項目主文件夾，在顯示的上下文菜單中使用 Team -> Share Project 選項
另一個選項是通過從選定的 CVS 資源庫分支導入代碼來創建新的工作臺項目。只要選擇適當分支（或 HEAD），然后選擇從 CVS Repository Exploring 透視圖中的上下文菜單中選擇“Checkout As Project”選項
2. 使用代碼并進行更改
開發人員通過 Eclipse 工作臺在本地使用代碼，包括的工作有創建新資源、修改現有資源、編寫注釋，并在他們使用后在本地保存這些內容。
3. 使本地更改與 CVS 資源庫同步
如果一個項目開發人員準備提交他／她的工作，那么首先要執行更新操作。這會針對引入的更改核對資源庫，并將這些更改添加到該開發人員的本地工作臺。這樣確保了開發人員知道這些更改可能會影響他／她將要提交的工作的完整性。使用項目上下文菜單中的 Compare With... 選項將本地版本與資源庫中存儲的代碼進行比較
下一步是解決最后出現的任何沖突，并設法再次編譯代碼。如果一切正常，那么從項目上下文菜單使用 Team -> Commit... 選項執行提交操作，如圖 6 所示。這會使所有更改都集成到資源庫中。
4. 管理資源庫
CVS 允許開發人員將更改隔離在開發的某些獨立路徑之內，這些路徑稱為分支。當一個開發人員更改某個分支上的文件時，這種更改不會出現在主干或其它分支上。那些分支被命名為子版本（subversion）或代碼分叉（code fork）。稍后，由合并操作將更改從一個分支遷移到另一個分支（或主干）。然后提交這些修訂。這樣就有效地將更改復制到了另一個分支上。使用項目上下文菜單的Team -> Branch...選項，Eclipse 使開發分支之間的遷移變得容易。
當然，當開發團隊維護大型資源庫時，有必要控制項目內的提交和合并操作。Eclipse/CVS 集成提供了一種特殊的視圖：CVS Repository History（請參閱圖 7）。它給出了關于團隊成員在資源庫中所執行更改的快速預覽。
Eclipse 平臺提供了幾個支持代碼管理的實用程序。最有用的是補丁功能。它將出自兩個來源（譬如本地工作臺和資源庫）的代碼進行比較，然后創建一個包含代碼差異的類似 UNIX 的補丁文件（請參閱圖 8）。可以將該文件發送給開發人員以將源代碼升級到最新版本。
5. 斷開項目與 CVS 的連接
當項目開發已經結束，并且團隊希望凍結源代碼時，可以從 HEAD 資源庫刪除該項目的最終版本。斷開項目與 CVS 的連接將在該項目及其資源上禁用資源庫操作，并刪除與該項目相關聯的 CVS 信息（這一操作是可選的）。
可以通過項目上下文菜單中的 Team -> Disconnect 選項執行斷開連接操作。通過選擇這個選項，會打開 Confirm Disconnect from CVS 對話框。在將該項目與資源庫的連接斷開之后，該團隊必須確定如何處理 CVS 信息。第一個選項是“Delete the CVS meta information”；它將禁用 CVS 團隊菜單操作并從文件系統中刪除 CVS 文件夾及其內容。第二個選項是“Do not delete the CVS meta information”；它將禁用 CVS 團隊菜單操作，但保留 CVS 元信息。
對第三方代碼管理應用程序的支持
CVS 有幾個重要的限制：它不能確定單個文件或整個文件集范圍內同時進行的更改，它也不能檢測文件之間的邏輯沖突。其沖突概念純粹是文本意義上的，當對于同一基本文件的兩個更改時間上非常非常接近，從而使合并命令受到干擾時，就會發生沖突。CVS 也不能提供任何類似于消息傳遞這樣的交互式協作工具。幸運的是，CVS 并不是 Eclipse 平臺所支持的唯一的源代碼管理軟件。開發人員可以通過插件擴展 Eclipse 平臺的功能，而且目前（到 2003 年 3 月 4 日為止）已有 16 個可用于團隊開發軟件的插件。所有插件都是由 Eclipse 社區或商業軟件供應商創建的。這些插件中的大多數添加了對第三方、商業源代碼管理系統的支持。最有價值的插件是那些支持流行的企業代碼管理系統（如 Merant PVCS 和 Rational ClearCase）的插件。例如，CVS-SSH2 插件允許通過 SSH2 會話訪問 CVS，而 Microsoft Visual SourceSafe（VSS）團隊提供程序插件添加了對 MS VSS 產品的支持（也可以在諸如 Linux 這樣的非 Windows 平臺上使用）。
但是，我本人所偏愛的插件是 Koi（請參閱參考資料以獲取鏈接）。盡管它并非嚴格用于源代碼控制，但這個創新的工具給協作開發注入了許多新的活力。其當前版本支持工作臺到工作臺的消息傳遞、共享標記、沖突更改通知、共享日歷和事件通知。Koi 將 XML-RPC 用作其客戶機-服務器體系結構中的通信模型。客戶機是與“協作服務器”通信的單個 Eclipse 平臺實例，而協作服務器也是一個 Eclipse 插件。Koi 使用以 JDBC 訪問的關系數據庫作為數據存儲。可在參考資料中找到指向完整的、經過分類的 Eclipse 插件注冊表的鏈接。
參考資料
請參加 eclipse.org 上的 Eclipse 平臺社區。Eclipse 平臺源代碼遵循 Common Public License。Eclipse.org 還有一個 Eclipse 項目的術語和描述詞匯表，以及技術文章和新聞組。Eclipse 平臺白皮書（可在 Eclipse.org 主頁獲取）詳細描述了 Eclipse 的主要組件和功能。
從 eclipse.org 下載 KOI 插件。
查看 Eclipse 插件的完整的、經過分類的注冊表。
從 CVS 主頁或 LORIA 站點下載 CVS 客戶機、服務器和源代碼。
請參閱 developerWorks 文章“Working the Eclipse Platform”，以了解關于 Eclipse 平臺的背景知識。
請參閱 developerWorks 文章“Getting started with the Eclipse Platform”，這篇文章介紹了用 Eclipse 平臺以及使用 Eclipse 插件編輯、編譯和調試應用程序。
請參閱 developerWorks 文章“開發 Eclipse 插件”，這篇文章介紹了如何開發 Eclipse 插件。
從 developerWorks 的這些文章中獲取關于 Eclipse 的更多信息：
在 developerWorks 開放源碼項目專區查找更多有關 Eclipse 和開放源碼參考資料。
?
關于作者
Pawel Leszek 是 Studio B 的一位作家，他是一位專長于 Linux/Win/Mac OS 系統體系結構和管理的獨立軟件顧問和作家。他具有許多操作系統、編程語言和網絡協議方面的經驗，尤其是 Lotus Domino 和 DB2 方面。Pawel 還在 LinuxWorld 上發表過一系列文章，他是 PC World 波蘭版的 Linux 專欄作家。Pawel 和他的妻子以及可愛的小女兒住在華沙。歡迎提問并提出意見；您可以通過 pawel.leszek@ipgate.pl 與 Pawel 聯系。
update 和 checkout 在執行中，會為每個文件打印一行提示信息，文件的狀態通過前面的單個字符指明:
?
U file
文件按要求從倉庫得到更新。用在那些倉庫里面有但你的工作目錄沒有的文件，以及工作目錄里面沒有修改過，但舊于倉庫的文件。
?
P file
類似 `U'，但是 cvs 服務器發送的是補丁而不是整個文件。完成與 `U' 同樣的工作，但降低帶寬的使用。
?
A file
添加到你的私人副本中，當你使用 commit 后會加到倉庫。這可以提醒你需要提交文件。
?
R file
從你的私人副本中刪除，當你執行 commit 命令后會從倉庫清除。這可以提醒你文件需要提交。
?
M file
在你的工作目錄中，文件已經修改。
`M' 可以標明你工作的文件的兩種狀態: 同樣的文件倉庫里面沒有修改，你的文件仍保持原樣; 或者倉庫里面的文件也有修改，但在工作目錄里成功合并，沒有沖突發生。
?
如果合并，cvs 將打印一些信息，并建立工作文件的備份(與 update 執行前相同)。update 運行時會打印相應的名字。
?
?
C file
合并你與倉庫中修改到 file 時檢測到沖突。file (你工作目錄里面的副本) 是合并兩個修訂版的結果; 工作目錄里面還有未修改文件的副本，名為 .#file.revision，其中 revision 是你修改的文件所基于的修訂版。解決沖突見 Conflicts example 說明。 (注意，在有些系統里面，如果一段日子沒有訪問 .# 起頭的文件，系統會自動清除。如果你需要保留這些原始的文件副本，最好將其改名) vms 系統中，文件名以 __ 開始，而不是 .#。
?
? file
file 處于工作目錄，但是倉庫里面沒有對應的文件，它們也不是 cvs 忽略的文件(參見 `-I' 選項的說明，以及參閱 cvsignore)。
?
?
update的幾個常用參數:
?
-D date
使用不遲于 date 的最新修訂版。這是一個粘性的選項，含有 `-P'。見 Sticky tags，了解更多粘性標簽/日期的信息。
?
-f
只與 `-D' 或 `-r' 標識一起使用。如果沒有匹配的修訂版，獲取最新的修訂版(而不是忽略這些文件)。
?
-k kflag
根據 kflag 處理關鍵字。參閱 Keyword substitution。此選項是粘性的; 以后在這個工作目錄里面更新，還是使用相同的 kflag。status 命令可以看到粘性的選項。參閱 Invoking CVS，了解 status 命令的信息。
?
-l
只在當前工作目錄里面執行。參閱 Recursive behavior.
?
-P
清除空目錄。參閱 Moving directories.
?
-p
管道方式輸出到標準輸出。
?
-R
遞歸方式檢出(默認)。參閱 Recursive behavior.
?
-r tag[:date]
獲得 rev 修訂版/標簽，或者當 date 指定，并且 tag 是分支標簽，分支 tag 上的版本可以當作是在 date 上。此選項是粘性的，含`-P'。參閱 Sticky tags 和 Common options 了解更多粘性標簽/日期的信息。
update 還有一些特殊的選項。
?
-A
重置任何的粘性標簽，日期，或 `-k' 選項。參閱Sticky tags，了解更多粘性標簽/日期的信息。
?
-C
用倉庫里面干凈的副本覆蓋本地的修改(但修改過的文件另存為 .#file.revision)。
?
-d
創建倉庫里面存在而工作目錄里面沒有的目錄。通常，update 只作用于你工作目錄里面已經存在的文件和目錄。
此選項通常用來更新最初檢出創建的目錄; 但也有不好的副作用。如果你在建立工作目錄時，刻意避免倉庫里面的某些目錄(通過模塊名，或在命令行上明確指定所需的文件和目錄)，用 `-d' 選項更新將創建這些你不想要的目錄。
?
?
-I name
更新時忽略匹配 name 的文件(在工作目錄里面)。你可以在命令行上多次使用 `-I' 指定多個要忽略的文件。`-I !' 可以避免忽略任何文件。參閱 cvsignore, 了解 cvs 忽略文件的其他方式。
?
-Wspec
指定更新時需要過濾的文件名。你可以重復使用此選項。
spec 可以是文件名模板，與 .cvswrappers 文件里面的類型相同。參閱 Wrappers.
?
?
-jrevision
通過兩個 `-j' 選項，合并第一個 `-j' 選項指定的修訂版至第二個 `j' 選項修訂版的變更到工作目錄。
使用一個 `-j' 選項，合并最初的修訂版至 `-j' 選項指定修訂版的變更到工作目錄。最初的修訂版是工作目錄文件基于的修訂版和 `-j' 選項指定修訂版共同的祖先。
?
注意使用 `-j tagname' 選項而不是 `-j branchname'，合并的通常不是從分支上刪除文件的變更。參閱 Merging adds and removals, 了解詳細情況。
?
另外，每個 `-j' 選項可以包含可選的日期規格，當用于分支時，可以限制修訂版處于指定日期之內。可選的日期通過分號(:)加在標簽里面: `-jSymbolic_Tag:Date_Specifier'.
?
?
本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/put2006/archive/2005/08/24/464318.aspx
總結
- 上一篇： head,branch,version,
- 下一篇： csharp attributes