[轉]版本控制工具

本文轉自:http://blog.csdn.net/moxie/archive/2005/01/19/258944.aspx

版本控制工具

    版本控制是程序開發、管理必不可少的工具,特別是在多人協作的團隊中,適宜的版本控制工具可以提高開發效率,消除很多有代碼版本帶來的問題。本文首先列舉沒有版本控制工具時可能遇到的問題,再對主流版本控制工具做概要介紹,之後對作爲Java開發者首選的版本控制工具CVS的歷史、功能、概念做詳細的介紹;最後在Eclipse+CVS環境中,以CVS使用的一個完整流程爲例,介紹如何正確的使用CVS工具。

爲什麼要使用版本控制工具?
如果沒有版本控制工具的協助,在開發中我們經常會遇到下面的一些問題:
一、 代碼管理混亂。如果是別人添加或刪除一個文件,你很難發現。沒有辦法對文件代碼的修改追查跟蹤。甚至出現文件丟失,或新版本代碼被同伴無意覆蓋等現象。
二、 解決代碼衝突困難。當大家同時修改一個公共文件時,解決代碼衝突是一件很頭疼的事。最原始的辦法是手工打開衝突文件,逐行比較,再手工粘貼複製。更高級的做法是使用文件比較工具,但仍省不了繁雜的手工操作,一不小心,甚至會引入新的bug。
三、 在代碼整合期間引入深層BUG。例如開發者A寫了一個公共函數,B覺得正好可以複用;後來A又對這個公共函數進行了修改,添加了新的邏輯,而這個改動的卻是B不想要的。或者是A發現這個公共函數不夠用,又新做了一個函數,B卻沒有及時獲得通知。這些,都爲深層BUG留下隱患。
四、 無法對代碼的擁有者進行權限控制。代碼完全暴露在所有的開發者面前,任何人都可以隨意進行增、刪、改操作,無法指定明確的人對代碼進行負責。特別是產品的開發,這是極其危險的。
五、 項目不同版本發佈困難。特別是對產品的開發,你會頻繁的進行版本發佈,這時如果沒有一個有效的管理產品版本的工具,一切將變得非常艱難。
    上面只是列舉了一些沒有版本控制系統可能帶來的問題,特別是對大型項目和異地協同開發有了一個合適的版本控制工具,它可以有效解決因爲代碼版本不同引起的各種問題,讓我們的開發人員能更多的把精力花費在開發上面。而不是每次都花費很多時間進行代碼整合和解決版本不同帶來的各種問題。

主流版本控制工具介紹
    現在,有很多優秀的版本控制工具供我們選擇,下面就五種主流的版本控制工具做簡單的介紹。
Starteam
    是一個集合了版本控制、構建管理(Build Management)和缺陷跟蹤系統爲一體的軟件,並且具有強大的圖形界面,易學易用;但管理複雜、維護困難。2002年底被Borland公司收購。
PVCS Version Manager
     是美國的MERANT公司軟件配置管理工具PVCS 家族中的一個組成部分,它能夠實現源代碼、可執行文件、應用文件、圖形文件和文檔的版本管理;它能安全地支持軟件並行開發,對多個軟件版本的變更進行有效的控制管理。
ClearCase(CC)
    是ROSE構件的一部分,目前最牛的配置管理工具,主要應用於複雜的產品發放、分佈式團隊合作、並行的開發和維護任務。可以控制word, excel,powerpoint,visio等文件格式,對於不認識的格式可以自己定義一種類型來標識。
Visual SourceSafe(VSS)
    簡單易用、方便高效、與Windows操作系統及微軟開發工具高度集成。
CVS(Concurrent Versions System)
    是開發源碼的併發版本系統,它是目前最流行的面向軟件開發人員的源代碼版本管理解決方案。它可用於各種平臺,包括 Linux 、Unix和 Windows NT/2000/XP等等。
    前面三種是重量級的商業版本控制工具,更適合龐大的團隊和項目,並且價格不菲。Visual SourceSafe是微軟的產品,當然只能用在windows平臺並與微軟的開發工具無縫集成。CVS免費開源,並且幾乎所有開源項目都是使用CVS進行版本管理,無疑,它是我們Java開發者最優選擇。

CVS的歷史、功能、基本概念的介紹

歷史

    CVS 誕生於 1986 年,當時作爲一組 shell 腳本而出現;1989年3月,Brian Berlinor用C語言重新設計並編寫了CVS的代碼;1993年前後,Jim Kingdon最終將CVS設計成基於網絡的平臺,開發者們能從Internet任何地方獲得程序源代碼。截至目前最新版本是2004年12月13日發佈的1.12.11。

功能介紹
一、 代碼統一管理,保存所有代碼文件更改的歷史記錄。對代碼進行集中統一管理,可以方便查看新增或刪除的文件,能夠跟蹤所有代碼改動痕跡。可以隨意恢復到以前任意一個歷史版本。並避免了因爲版本不同引入的深層BUG。
二、 完善的衝突解決方案,可以方便的解決文件衝突問題,而不需要藉助其它的文件比較工具和手工的粘貼複製。
三、 代碼權限的管理。可以爲不同的用戶設置不同的權限。可以設置訪問用戶的密碼、只讀、修改等權限,而且通過CVS ROOT目錄下的腳本,提供了相應功能擴充的接口,不但可以完成精細的權限控制,還能完成更加個性化的功能。
四、 支持方便的版本發佈和分支功能。

基本概念
資源庫(Repository)

CVS的資源庫存儲全部的版本控制下的文件copy,通常不容許直接訪問,只能通過cvs命令,獲得一份本地copy,改動後再check in(commit)回資源庫。而資源庫通常爲與工作目錄分離的。CVS通過多種方式訪問資源庫。每種方法有不同目錄表示形式。
版本(Revision)
每一個文件的各個版本都不相同,形如1.1, 1.2.1,一般1.1是該文件的第一個revision,後面的一個將自動增加最右面的一個整數,比如1.2, 1.3, 1.4...有時候會出現1.3.2.2,原因見後。revision總是偶數個數字。一般情況下將revision看作時CVS自己內部的一個編號,而tag則可以標誌用戶的特定信息。
標籤(Tag)
用符號化的表示方法標誌文件特定revision的信息。通常不需要對某一個孤立的文件作tag,而是對所有文件同時作一個tag,以後用戶可以僅向特定tag的文件提交或者checkout。另外一個作用是在發佈軟件的時候表示哪些文件及其哪個版本是可用的;各文件不同revision可以包括在一個tag中。如果命名一個已存在的tag默認將不會覆蓋原來的;
分支(Branch)
當用戶修改一個branch時不會對另外的branch產生任何影響。可以在適當的時候通過合併的方法將兩個版本合起來;branch總是在當前revision後面加上一個偶數整數(從2開始,到0結束),所以branch總是奇數個數字,比如1.2後面branch爲1.2.2,該分支下revision可能爲1.2.2.1,1.2.2.2,...
衝突(Conflct)
完全是純文本的衝突,不包含邏輯上的矛盾。一般是一份文件,A做了改動,B在A提交之前也做了改動,這樣最後誰commit就會出現衝突,需要手工解決衝突再提交。

CVS與eclipse集成開發
  前面對CVS的歷史、功能、概論等理論知識做了介紹。下面我們將使用最流行的Java IDE Eclipse中內置的CVS工具,以一個完整開發流程,介紹實際環境中CVS的正確使用。關於CVS系統的安裝,不是本文的內容,您可以從附錄的鏈接中獲取安裝的介紹資料。

常用的CVS控制命令
Check Out(檢出)
把源文件從cvs源代碼倉庫中取出,缺省的版本是最新的版本,你也可以選擇指定的版本。在每次更改源代碼之前,需要Check Out最新的版本,再起基礎之上對源代碼進行修改。將代碼目錄checkout到指定目錄下,所有文件都是read-write。
Check In(檢入)
把源代碼加入到cvs源代碼倉庫中,每一個添加進代碼庫中的文件的版本是 1.1。以後每次修改文件重新ci以後,此文件的版本遞增爲1.2 ,1.3.……。在每次對源代碼修改之後,需要Check In,提交最新版本的源代碼。
Synchronize with Repository(與資源庫同步,簡稱同步)
使本地更改與資源庫同步,它會列出本地和資源庫之間不同的所有文件。
Add to Version Control
將新的文件加入到版本控制之中。
Add to .cvsIgnore
將文件設置到版本控制之外,這樣該文件或目錄中的文件的更改在CVS中不可見,即使同步也無法發現。

CVS正確使用步驟
一、 同步(Synchronize)

就是將本地更改與服務器同步,同步之後可以清晰的看到上一撿出(Check Out)版本之後本地、服務器上的最新改動。這是非常有用的,特別是敏捷開發,強調集體擁有代碼。有了同步功能,你可以全局把握項目的代碼,可以很方便的跟蹤公共模塊代碼的任何改動。
具體操作:在Eclipse的資源視圖(Resource Perspective)或者Java視圖(Java Perspective)中,選中要同步的目錄,點擊右鍵選擇"Synchronize with Repository",之後它將顯示同步的視圖。如下圖:
 
(圖一、CVS同步視圖)
同步之後,它有四種Mode可以選擇,見上圖綠色框框裏按鈕。從做到右分別爲:
Incoming Mode:表示修改是來自服務器,對應於更新(update)操作。
Outgoing Mode:表示修改是來自本地,對應提交(commit)操作。
Incoming/ Outgoing Mode:本地和服務器修改都在該模式(Mode)中顯示。
Conflicts Mode:顯示本地和服務器修改的衝突文件。
二、 更新(update)
比較簡單,選擇Incoming Mode,再選中要更新的文件,右鍵選擇update操作。
三、 解決衝突併合並(solve conflct and merge)
如果有衝突文件,衝突文件不能更新。你必須先解決衝突再操作。選中衝突的文件,再點右鍵選擇"Open in Compare Editor",用比較工具打開該文件。如下圖:

(圖二、CVS比較器視圖)

比較器(Compare)視圖,左邊版本底的是本地文件(Local File),右邊是遠程服務器文件(Remote File)。使用"Select Next Change"按鈕(綠框中的第一箭頭向下按鈕),逐一查看不同點。如果不同點標識爲黑色框框,則不用管它。如果是藍色框框,則需要手工調整。如上圖,不同點是藍色框框,將鼠標放到兩個不同點的中間小方框中,則凸出一個向右的按鈕,並顯示提示信息"Copy Current Change from Right to Left",意思是將右邊服務器的不同點覆蓋到左邊的本地文件。點中此按鈕。重複這樣的操作,將所有服務器上的更改拷貝到本地。
如果有一行代碼,本地和服務器都同時做了修改。這時,修改點則顯示紅色框框。這時,你就必須手工做正確的修改。全部修改完成,保存本地文件。
此時,如果修改點沒有了藍色的框框,就可以開始做合併(merge)操作了。操作也很簡單,選擇該文件,點擊右鍵,選擇"Mark as merged"。
注意:必須確保沒有藍色框框,即完全拷貝了服務器的修改纔可以做合併(merge)操作,否則會覆蓋服務器上的代碼。
四、 提交(commit)
更新服務器代碼,解決衝突之後,首先要查看本地文件修改之後是否有錯誤。如果有,當然首先解決錯誤,再提交。

附錄:
http://www.8848software.com/scmchina/scmtools.htm 由很多版本控制工具的文檔鏈接。
http://www.perforce.com/perforce/reviews.html Infrastructure Group對Perforce 和Clearcase, CVS, PVCS,Visual SourceSafe (VSS)幾種CM工具進行了定量和定性的比較. 對於定性的比較,內容涉及工具支持的方法和環境;對於定量的比較,包括在不同的項目規模上,執行不同的活動所需要的時間

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章