【文章內容簡介】 S 服務器與客戶端安裝與配置方法。 第四章 主要詳細展示 Linux 環(huán)境下 CVS 服務器與 CVS 客戶端安裝與配置方法。 第五章 主要演示了在搭建好的 CVS 服務器環(huán)境和客戶端環(huán)境下項目中CVS 版本控制的應用。 第六章 主要闡述了 CVS 版本控制系統(tǒng)的開源化對于協(xié)同工作，或者對于大型軟件系統(tǒng)開發(fā)的影響，以及介紹了兩款與 CVS 版本控制系統(tǒng)配合使用的軟件。河南城建學院本科畢業(yè)設計（論文） 基于 CVS的版 本控制系統(tǒng)介紹 5 2 基于 CVS的版本控制系統(tǒng)介紹 什么是 CVS CVS是一個 C/S系統(tǒng)，多個開發(fā)人員通過一個中心版本控制系統(tǒng)來記錄文件版本，從而達到保證文件同步的目的。 CVS版本控制系統(tǒng)是一種 GNU軟件包，主要用于在多人開發(fā)環(huán)境下的源碼的維護。與它相類似的代碼版本控制軟件有Subversion。 CVS的基本概念 1） Repository（倉庫） CVS 的倉庫存儲全部的版本控制下的文件 copy，通常不容許直接訪問，只能通過 cvs命令，獲得一份本地 copy，改動后再 check in（ mit） 回倉庫。而倉庫通常為與工作目錄分離的。 CVS通過多種方式訪問倉庫。每種方法有不同目錄表示形式。數據如何存放在 repository中：隨著 CVS版 本的不同，存放結構會發(fā)生變化，一般情況下用戶無需了解數據到底是如何存放的。 2） Revision（修訂版） 每 一個 file的各個 revision都不相同，形如 , ,一般 個 revision，后面的一個將自動增加最右面的一個整數，比如 , , ...有時候會出現 ，原因見后。 revision總是偶數個數字。一般情況下將 revision看作時 CVS自己內部的一個編號，而 tag則可以標志用戶的特定信息。 3） Tag（標簽） 用符號化 的表示方法標志文件特定 revision的信息。通常不需要對某一個孤立的文件作 tag，而是對所有文件同時作一個 tag，以后用戶可以僅向特定 tag的 文件提交 或者 checkout。另外一個作用是在發(fā)布軟件的時候表示哪些文件及其哪個版本是可用的；各文件不同 revision可以包括在一個 tag中。 如果命名一個已存在的 tag默認將不會覆蓋原來的； 4） Branch（分支） 當用戶修改一個 branch時不會對另外的 branch產生任何影響。可以在適當的時候通過合并的方法將兩個版本合起來； branch總是在當前 revision后面加上一個偶數整數（從 2開始，到 0結束），所以 branch總是奇數個數字，比如 branch為 ，該分支下 revision可能 為 ,... 河南城建學院本科畢業(yè)設計（論文） 基于 CVS的版本控制系統(tǒng)介紹 6 5） Conflict（沖突） 完全是純文本的沖突，不包含邏輯上的矛盾，比如 CVS不能解決如下問題：某人修改了函數 f的參數，而另外一個人在另外一個地方用老的參數調用該函數。文本沖突需要用戶自己參與解決， CVS無法自動解決。 6） Module（模塊） CVS服務器根目錄下的第一級子目錄。通常用于存放一個項目的所有文件 7） Check out（檢出） 通常指將倉庫中的一整個模塊首次導出到本地。 8） Check in（導入） 通常指通過提交整個目錄結構并創(chuàng)建一個新的模塊。 9） Release（發(fā)行版本） 整個產品的版本 10） Update（更新） 從模塊中下載其他人的修改過的文件。更新本地的拷貝。 11） Commit（提交） 將自己修改過的文件提交到模塊中。 CVS的工作模式和工作思路 CVS（ Concurrent Versions System）版本控制系統(tǒng)是一種 GNU軟件包，主要用于在多人開發(fā)環(huán)境下的源碼的維護。 Concurrent有并發(fā)的、協(xié)作的、一致的等含義。實際上 CVS可以維護任意文檔的開發(fā)和使用，例如共享文件的編輯修改，而不僅僅局限于程序設計。 CVS維護 的文件類型可以是文本類型也可以是二進制類型。 CVS用 CopyModifyMerge（拷貝、修改、合并）變化表支持對文件的同時訪問和修改。它明確地將源文件的存儲和用戶的工作空間獨立開來，并使其并行操作。 CVS基于客戶端 /服務器的行為使其可容納多個用戶。這一特性使得 CVS成為位于不同地點的人同時處理數據文件（特別是程序的源代碼）時的首選。 所有重要的免費軟件項目都使用 CVS作為其程序員之間的中心點，以便能夠綜合各程序員的改進和更改。這些項目包括 GNOME、 KDE、 THE GIMP和 Wine等。 在一臺服務器 上建立一個源代碼庫，庫里可以存放許多不同項目的源程序。由源代碼庫管理員統(tǒng)一管理這些源程序。每個用戶在使用源代碼庫之前，首先要把源代碼庫里的項目文件下載到本地，然后用戶可以在本地任意修改，最后用CVS命令進行提交，由 CVS源代碼庫統(tǒng)一管理修改。這樣，就好像只有一個人在修改文件一樣，既避免了沖突，又可以做到跟蹤文件變化等。 河南城建學院本科畢業(yè)設計（論文） 基于 CVS的版本控制系統(tǒng)介紹 7 CVS是并發(fā)版本系統(tǒng)（ Concurrent Versions System）的意思，主流的開放源碼網絡透明的版本控制系統(tǒng)。 CVS對于從個人開發(fā)者到大型、分布團隊都是有用的。 它的客戶機 /服務 器存取方法使得開發(fā)者可以從任何因特網的接入點存取最新的代碼。它的無限制的版本管理檢出 (check out：注 1)的模式避免了通常的因為排它檢出模式而引起的人工沖突。它的客戶端工具可以在絕大多數的平臺上使用。 CVS被應用于流行的開放源碼工程中，像 Mozilla， GIMP， XEmacs， KDE和 GNOME等。那么它到底怎么樣？ 你可能會說，它非常棒，但是對于 我 來說它能做什么？首先，基本的 ：一個版本控制系統(tǒng)保持了對一系列文件所作改變的歷史記錄。對于一個開發(fā)者來說，那就意味著在你對一個程序所進行開發(fā)的整個期 間，能夠跟蹤對其所作的所有改動的痕跡。對你來說，有沒有出現過由于在命令行上按錯鍵而導致一天的工作都白費的情況呢？版本控制系統(tǒng)給了你一個安全的網絡。 版本控制系統(tǒng)對任何人都有用，真的。 (畢竟，誰不愿意使用一個安全的網絡呢？ )它們經常被軟件開發(fā)團隊使用。在團隊中工作的開發(fā)者需要能夠調整他們的各自的修改；一個集中式版本控制系統(tǒng)允許那樣做。 CVS代碼的集中配置與調整 個人開發(fā)者希望一個版本控制系統(tǒng)的安全網絡能夠運行在他們的本地的一臺機器上。然而，開發(fā)團隊需要一個集中的服務器，所有的成員可以將服務器作為倉庫 來訪問他們的代碼。在一個辦公室中，沒有問題 只是將倉庫連到本地網絡上的一臺服務器上就行了。對于開放源碼項目 … 噢， 還是沒有問題，這要感謝因特網。 CVS內建了客戶機 /服務器存取方法，所以任何一個可以連到因特網上的開發(fā)者都可以存取在一臺 CVS服務器上的文件。 在傳統(tǒng)的版本控制系統(tǒng)中，一個開發(fā)者檢出一個文件，修改它，然后將其登記回去。檢出文件的開發(fā)者擁有對這個文件修改的排它權。沒有其它的開發(fā)者可以檢出這個文件 并且只有檢出那個文件的開發(fā)者可以登記 (check in：注 2)所做的修改。 (當然對于管理員有很多 方法可以超越這個限制。 ) 想一下排它的檢出可能會如何工作： Bob的兄弟檢出 ，寫好代碼后他什么也沒做。然后他去吃午飯了。 Bob吃完午飯后，發(fā)現他的老板所指給他的一個 bug在 。他試圖檢出 … 但是版本控制系統(tǒng)不允許他這樣做，因為他的兄弟已經把它檢出了。 Bob不得不等著他的兄弟吃完午飯回來 (在這個 好 日子用了兩個小時 )，他才可以修正 bug。 河南城建學院本科畢業(yè)設計（論文） 基于 CVS的版本控制系統(tǒng)介紹 8 在一個大型的開放源碼工程中，因為開發(fā)者可能在任意的時區(qū)工作得很晚，給予一個開發(fā)者阻止任意地方的其它開發(fā)者 繼續(xù)處理任意文件的能力很明顯無法運轉。他們最終將因為不能夠在他們想要的時候開展項目而感到厭煩。 CVS通過它的無限制的檢出模式解決了這個問題。檢出一個文件并不給定開發(fā)者對那個文件的排它權。其它的開發(fā)者也可以對其檢出，進行他們自己的修改，并且將其登記回去。 詳細地回答就是當多個開發(fā)者對同一個文件作了修改 CVS會檢測，并且自動合并那些改變。 不用擔心 ， CVS會很小心，并且將會自動合并那些只要不是對代碼的同一行所作的改動。如果 CVS不能安全的處理這些改動，開發(fā)者將不得不手工合并它們。 有大量在許多平臺上可用的 CVS附加工具，它們給 CVS增加了功能或使得CVS更容易使用。 CVS的典型功能 1） 替代管理 你的經理和項目負責人應經常與你交流以確保你時時記得進度表、合并點、分支名和發(fā)布日期。如果他們不這樣做， cvs 也沒用。 cvs 只是一個用來使你的資源與你的步調一致的工具。但你是風笛手和作曲家，沒有哪種樂器會自己演奏或是作曲。 不能代替開發(fā)者之間的交流。在單個文件內遇到沖突時，大多數開發(fā)者不費多大力氣就能解決它們。但更常見的 沖突 (conflict)，是那些難度較大、不在開發(fā)者之間進行交流就沒法解決的問題。 當在一個文件內或多個文件中同時發(fā)生變化時， cvs 并不知道何時它們會在邏輯上發(fā)生沖突。它的沖突 (conflict)概念是純粹文本意義上的，這種沖突會在同一個文件的兩種變化十分接近以致于會破壞合并命令 (如 diff3)。 CVS決不會指出程序邏輯上非文本或分布式的沖突。例如：假如你改變了在文件 A 中定義的函數 X 的參數。同時，別人在編輯文件 B，仍用舊參數調用 X 這個函數。此時產生的沖突 cvs 可就無能為力了。 2） 變化控制 變化控制可以指許多事情。首先它的意思可以是 BUG 跟蹤 bugtracking，就 是說它能維持一個數據庫，其中包括已報告的 BUG 和每一個 BUG 狀態(tài) (是否已更正？在哪一個版本中？提交這個 BUG 的人是否認為已經更正？ )。為了使 cvs 和一個外部的跟蹤 BUG 系統(tǒng)協(xié)調一致，請參考 rcsinfo 和 verifymsg文件 (參閱 Administrative files)。 河南城建學院本科畢業(yè)設計（論文） 基于 CVS的版本控制系統(tǒng)介紹 9 變化控制的另一個方面指跟蹤這樣的情況，即對好幾個文件的改變實際上只是同一個邏輯變動。如果你在一次 cvs mit 操作中檢入幾個文件， cvs 會忘掉它們是一起檢入的，它們共用一個 LOG 信息的事實 只是把它們綁在一起而已。做一個 gnu 風格的 ChangeLog 可能會有點用。在一些系統(tǒng)中，變化控制的另一個方面是跟蹤每個變化的狀態(tài)的能力。一些變化由一個開發(fā)者寫出，而另一些變化則由另一個開發(fā)者來作出評論，等等。一般來講，用 cvs 來做，是產生一個 diff（用 cvs diff 或 diff），并且用電子郵件寄給某人，此人就可以用 patch 來應用它。這是非常靈活的，但依賴于 cvs 之外的機制以保證事情不會崩潰。 3） 自動測試 強制利用 mitinfo文件測試套件應該是可能的。不過我沒有聽 說過多少項目試圖那樣做或那里有微妙的陷阱。 4） 內置處理 有些系統(tǒng)提供一些方法確保變更或發(fā)布通過不同的步驟，以及各種所需的批準過程。一般地，你可以用 cvs 來完成它，但是可能要多做點工作。有些情況下你想用 mitinfo、 loginfo、 rcsinfo 或 verifymsg文件，要求在 CVS 提交之前完成某些操作。你也會考慮諸如 branches 和 tags等特性是否能用在一個開發(fā)樹中執(zhí)行任務，然后僅當它們被證實就把某些修改合并到一棵穩(wěn)定的樹中。 CVS 還有一個更加重要的特性：能記下每個文件的 每次修改，以及如何被修改 … 對于基于 Inter 的合作方式來說，這些特性太重要了。一個地域上分散的自愿者組織顯然不可能投入很多的時間來訓練其成員彼此合作。因為這樣的話，當該組織有成員變更的時候，為此付出的投資將損失殆盡。所以需要指定一套基本的項目分配方案，以確保新成員能較容易的適應工作，同時也需要設置一個自動的系統(tǒng)來接受外來代碼，并使每個成員能及時得到最新修改的代碼。 河南城建學院本科畢業(yè)設計（論文） Windows下 CVS服務器與客戶端的配置 10 3 Windows 下 CVS服務器與客戶端的配置 Windows 下 CVS服務器的配置 CVS是目前最常用的版本控制和軟件配置系 統(tǒng)。其開源性在其普及的過程中功不可沒，然而正因為開源造成了其易用性較差。往往一個功能需要通過幾個看似不相干的操作配合才能進行。 Windows下 CVS的多帳戶配置正是這樣一個相當重要的，但很不好操作的功能。幾個難點如下： CVS源自 Unix系統(tǒng)，其 Windows的移植版并沒有服務器功能。在 Windows下一般采用安裝 CVSNT這個軟件來建立 CVS Repository，但 CVSNT的