複製鏈接
請複製以下鏈接發送給好友

版本管理器

鎖定
如果説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格式。