版本管理器

版本管理器

如果說70年代的軟體危機導致了軟體工程思想的誕生和理論體系的發展,那么80~90年代尤其是90年代軟體產業的迅猛發展導致了另一種新思想的產生和實現,這就是軟體的版本管理。

基本介紹

  • 中文名:版本管理器
  • 外文名:Version Manager
  • 誕生時期:90年代
  • 原因:軟體開發的複雜性
  • 用途:管理項目程式
  • 具體實例:Visual SourceSafe 6.0(VSS 6.0)
必要性,發展史,相關軟體,

必要性

只要參加過軟體開發的人都清楚,現在的軟體項目完全由一個人來完成是難以想像而且也是不可能的,通常是有一個研發小組來共同分析、設計、編碼和維護,並有專門的測試小組對已完成編碼調試的軟體進行全面的測試。在軟體開發這個龐大而複雜的過程中,需要涉及到各個方面的人員,信息的交流反饋不僅僅是在研發小組的成員之間及各個研發小組之間,還存在於客戶和研發者之間。所有的這些交流反饋意見信息都有可能導致對軟體的修改,小的可能只是對某個源檔案中的某個變數的定義改動,大到重新設計程式模組甚至可能是整個需求分析變動。在這個工程中,由於軟體開發所固有的特徵,可能會形成眾多的軟體版本,而且我們並不能保證不出現錯誤的修改,而這樣的一個困難局面卻又非常現實地擺在項目開發管理者的面前,他/她該如何有效地解決這些問題,具體地說就是如下一些問題:
1. 怎樣對研發項目進行整體管理;
2. 項目開發小組的成員之間如何以一種有效的機制進行協調;
3. 如何進行對小組成員各自承擔的子項目的統一管理;
4. 如何對研發小組各成員所作的修改進行統一匯總;
5. 如何保留修改的軌跡,以便撤銷錯誤的改動;
6. 對在研發過程中形成的軟體的各個版本如何進行標識,管理及差異識辨等等。
一個非常直接的反應,我們必須要引進一種管理機制,一個版本管理機制,而且是廣義上的版本管理,它不僅需要對原始碼的版本進行管理,而且還要對整個項目進行管理。以往的那種被譽為具有良好編程風格的做法,諸如在對他人的源程式進行修改時注釋修改原因,修改人和日期,如果是多個成員同時進行了修改,那么需要進行及時的人工的差異比較和綜合以便形成一個統一的新版本。這種做法在當前的大型軟體的開發中已經越來越沒有空間了,可以說是一種以小作坊的形式來面對軟體的社會化大生產,再也不可能行得通了。
其實,版本管理的思想很早就存在於軟體開發者的頭腦之中,只是以往的認識沒有現在人們所意識到的那樣迫切。UNIX的程式開發系統較早就提供了能夠進行開發小組中原始碼版本管理的工具,現在的Linux更是提供功能強大的能夠跨平台的版本管理器,國外公司的基於Windows的版本管理器也已經有了比較成熟的產品,國內的研究單位如北京大學計算機系CASE實驗室也在致力於這方面的工作。在眾多的成熟產品和試驗產品中,這裡只將對使用比較廣泛,有較大用戶前景且又能較易獲得的版本管理器產品Microsoft公司的Visual SourceSafe 6.0進行詳細的介紹,針對普通的研發小組的解決方案,及具體的實現。

發展史

史前時期
1982年的RCS。現在你可能還能在Unix的發布包中找到它。古典時期
版本管理器
1990年的CVS(經典的SCM管理器,可惜不能track目錄和檔案名稱的改變,今天這個東西已經過時了),1985年的PVCS,1992年的clearcase(價格貴,功能複雜,當然,今天也有很多公司在用),微軟的VSS(Welcome to Hell),90年代中期的Perforce(P4,這個工具今天都還在被廣泛地使用,尤其是那些中等大小卻有著大量開發團隊的公司,現在是Google內部最大的代碼管理器)。
中世紀時期
SVN(Linus很不喜歡SVN,2006年引入了Git),AccuRev(強力支持branch和merge,其扮演了一個很重要角色幫助社區脫離clearcase和CVS)。
文藝復興時期
BitKeeper——Sun的內部管理工具,Linux的核心代碼2002年也用這個工具,其實,很多開源工程都在用這個工具,2005年這個工具的東家BitMover對大家對BitKeeper逆向工程很不滿,於是停止支持開源,於是出現了Git。
Git的第一個版本是Linux之父Linus Torvalds親手操刀設計和實現的(據說只用了一個周末),Linus不僅僅給出一個原始設計(簡單的、乾淨的、天才的),同時,他也用自己那獨一無二的風格催生了這個項目。在Linus介紹Git的著名的演講中,他強烈地批評(好吧,應該算是侮辱)了CVS,SVN,和Perforce:“Subversion是史上最毫無意義的項目,從項目開始就是這樣了”,“如果你喜歡CVS,那么你現在應該在某個精神病研究中心或是別的地方”,“別在用Preforce了,它是十分糟糕和可悲的,這絕對絕對是真的”。無論是反對還是喜歡,Linus的確是改變了歷史——中世紀已經過去了,現在的世界由分散式系統主宰,以及消除branch和merge的恐懼。Git 基於 DAG 結構 (Directed Acyclic Graph),其運行起來相當的快。在Git發布後的來年,世界上所有的大型的開源項目全部從Subversion遷移到了Git上,真是很大,這可能是這具星球上最強大最牛最酷的SCM系統了。Git可能並不是最簡單的,但它一定會是未來十年的主流。
Mercurial (Hg) 第一次出現在2005年4月,也是因為BitKeeper不免費了。Hg可以和Git在一起使用,但是Hg和Git在設計上不一樣,他們對提交/變更的概念是一樣的,只不過Git用tree來實現,而Hg則是用扁平的檔案和目錄來實現(revlog)
Darcs (Darcs Advanced Revision Control System)是另一個讓你擺脫Subversion和CVS的工具,2002年開始,今年是2.5版。它的優勢是性能,以及他與眾不同的歷史版本管理——管理patches而不是snapshot(提交/修改),當然,這樣一來,歷史改變看上去很不好懂。
Bazaar (bzr) 是另一個開源的 DVCS,它試圖給SCM的世界裡帶來一些新的東西。其由Canonical開發(Ubuntu的那個公司),在2008年成為GNU。
Plastic在2006年出現,強力地支持branch和merge,其還提供了強大的圖示,包括3D的版本樹,Plastic主要是為了讓中等開發團隊使用,介於大型的團隊(ClearCase)和小型的團隊(Subversion)之間。
Team Foundation Server (TFS),微軟的新一代SCM工具,主要是為了VSS的失敗負責,但是他還不是版本管理上還是很強,只不過,他集成了一大堆各種各樣的工具,比如:issue tracking,test management等。

相關軟體

VSS 6.0現在是作為Microsoft Visual Studio 6.0這個開發產品家族的一員,如Visual C++ 6.0和Visual J++ 6.0一樣。
1. VSS的簡單工作原理
Microsoft的VSS 6.0解決了軟體開發小組長期所面臨的版本管理問題,它可能有效地幫助項目開發組的負責人對項目程式進行管理,將所有的項目源檔案(包括各種檔案類型)以特有的方式存入資料庫。開發組的成員不能對該資料庫中的檔案進行直接的修改,而是由該版本管理器將該項目的源程式或是子項目的源程式拷貝到各個成員自己的工作目錄下進行調試和修改,然後將修改後的項目檔案作Checkin提交給VSS,由它進行綜合更新。VSS也支持多個項目之間檔案的快速高效的共享。當某個成員向VSS中添加檔案時,該檔案將會被備份到資料庫中,以便所有的成員都能共享該檔案。而且每個成員對所有的項目檔案所作的修改都將被記錄到資料庫中,從而使得修改的恢復和撤銷在任何時刻,任何位置都成為可能。小組的成員可能得到該項目的最新版本,對它進行修改,並保存一個新的版本。
VSS的項目組織管理使得開發小組的協調變得簡單容易且很直觀,當一個和一組檔案發放給另一個成員,小組,Web站點或是任何其他的地址,VSS確保他們之間的真正共享及所選的一組檔案的不同版本的安全性。現在,越來越多的開發者可以通過他們的開發環境來訪問VSS的功能。而且VSS可以很容易地於Microsoft Access、 Visual Basic、 Visual C++、Visual FoxPro和其他的開發工具集成在一起,一旦VSS集成到開發環境中,就可以象控制項一樣使用,能夠很好地體現出VSS的易用性和強大功能。
2.VSS中的幾個重要概念
為了更好的了解VSS,有必要對如下一些概念給予說明。
首先是項目的概念,所謂的項目是一組存在VSS中的檔案(任何類型),可以在項目中或是項目之間進行檔案的添加、刪除、編輯和共享。一個項目與作業系統的資料夾有很多的相似之處,但它更好地支持檔案合併、歷史和版本控制。所有的檔案存在VSS資料庫的項目中,開發組成員不能在VSS中的主備份檔案上工作(除了檢查和版本比對等特殊情況外)而是VSS為每個成員在各自的工作目錄下提供一個拷貝以供工作。儘管在沒有工作目錄的情況下也可以查看某個檔案,但如要真正在VSS管理下工作,就必須要創建一個工作目錄。   VSS能夠維護一個檔案的多個版本,包括一個從不同版本之間進行修改的記錄。版本控制包括如下方面:
組內協調—在一般情況下,確保在任何時刻都只有一個成員對某個特定的檔案進行修改,這樣可以防止檔案被其他成員的修改意外更新。當然,VSS管理員可以改變此預設設定以允許對單個檔案同時有多個Checkout,並且仍禁止對他人的修改進行覆蓋。
版本跟蹤—對老版本的原始碼和其他檔案進行歸檔和跟蹤,而且這些版本能夠被重新得到以便進行bug跟蹤或其他目的。
跨平台開發—支持同一代碼在跨多個開發平台時的版本控制
重用或面向對象代碼—跟蹤哪些程式使用了哪些代碼可被重用的模組。
版本控制的涵義在以後的章節中將會得到更進一步的論述。
我們已經知道,VSS 提供版本控制和歷史服務,以保證一個檔案的每個版本都是可恢復的。VSS用日期/時間戳來記錄檔案是何時被Checkout或是何時被修改的,它主要有三種方法來跟蹤檔案和項目的版本:
版本號:這是由VSS維護的內部數碼,用戶對它沒有控制權。每個檔案和項目的每個版本都有一個版本號,這些版本號總是一個整數且是遞增的。
標籤:這些是用戶賦給某個項目或檔案的某個版本的一個字元串,可以是任何格式的長度不超過31字元的字元串。
日期/時間戳:它給出了一個檔案何時最後被修改的信息,或者是一個檔案何時被Checkin。VSS同時支持12小時和24小時的時間格式。
工作目錄是用戶真正對項目檔案進行調試修改的地方,當用戶Checkout 或提取一個檔案時,VSS將該項拷貝到用戶的工作目錄下,當用戶修改了該檔案並將其Checkin或提交時,VSS再將它從用戶的工作目錄拷回到VSS的資料庫中。在用戶作Checkout時,VSS將會自動管理他的工作目錄,諸如創建必要的子目錄。而且工作目錄可以隨時創建或修改。
3. VSS 6.0的一些新增的特徵和功能
歸檔和恢復—在VSS 6.0中這兩個操作是在一個用戶界面友好的VSS管理員wizard中進行的,而在以前的版本中,它們只能通過命令行來實現。
移動檔案—當用戶移動檔案時,VSS 6.0自動將該檔案共享到一個新的項目中,並在原項目中將其刪除。在新項目中,該檔案的屬性是共享的。
多個項目之間的差異比較—該功能允許用戶在不同的項目之間進行差異比較。
單個檔案的展開—在以前的版本中,VSS只能展開一個目錄(資料夾),在VSS 6.0中,同時可以展開一個檔案。
快速提取—由於VSS 6.0在性能上的提高,現在的檔案提取速度比以往VSS版本的快兩倍左右。
歷史信息過濾—VSS 6.0 支持查看那些沒有標籤的檔案和項目的歷史。
清除臨時資料夾選項—該新功能可使用戶很方便地清除臨時資料夾。
檢查外部的超連線—在VSS 的較早的版本中,只有內部的超連線和項目內的跳轉才得到檢查,VSS 6.0允許用戶檢查項目之外的超連線和跳轉。
創建打開VSS資料庫的快捷鍵—用戶可以使用VSS Explorer中該新功能創建一個打開某個特定VSS資料庫的桌面快捷鍵。
HTML格式的幫助—VSS的以往版本使用的是WinHelp格式。

相關詞條

熱門詞條

聯絡我們