Subversion使用手冊

1、Subversion使用手冊配置Subversion版本控制選用Subversion，它對重構(gòu)的支持比CVS要好。例如改名，原子提交等CVS無法支持的操作。下載Subversion的Win32自動安裝包，安裝至D:Subversion。安裝包會自動添加Path等變量。建立D:SVNRepo文件夾，作為代碼的根目錄?？砂惭bTortoiseSVN作為Client。執(zhí)行命令：svnadmin create D:svnrepo或通過TortoiseSVN建立repo根目錄。立即就可以使用client通過file:/d:/svnRepo來訪問該目錄。SVN有3種常用訪問方式。通過file:/, svn:

2、/,http:/ 等不同的協(xié)議來訪問。對于協(xié)作開發(fā)，這三種都可以勝任：如果在同一局域網(wǎng)內(nèi)，可通過windows的文件共享協(xié)議來訪問其他機器上的文件，例如file:/server/d/svnrepo。svn協(xié)議使用3690端口，如果防火墻無法打開端口，可與Apache整合使用http協(xié)議。采用svn協(xié)議的好處是安全性比較強，可任意更改服務(wù)監(jiān)聽端口。運行%SVN_HOME%binsvnserve d r d:svnrepo，即可按照daemon方式來運行一個后臺進程，監(jiān)聽svn協(xié)議的請求。-r的作用是聲明root目錄。在linux下運行一個daemon進程非常簡單，但是在windows中想讓進程在

3、后臺運行就需要做成服務(wù)才行。下載并安裝SVN Service Wrapper，將svnserve包裝為服務(wù)。執(zhí)行：svnservice -install -d -r d:svnrepo，在控制面板->服務(wù)中手動開啟。用TortoiseSVN瀏覽svn:/localhost/，注意要帶上最后的“/”指明root才能正確訪問。使用版本控制必須要進行權(quán)限控制，svn協(xié)議的權(quán)限控制可通過ssh來控制，訪問協(xié)議則改為：svn+ssh:/localhost/，windows下這種方式需要安裝ssh客戶端。另一種簡易的版本控制為使用passwd文件。修改%REPO_HOME%/conf/ svnser

4、ve.conf，包含如下幾句：    general    # 指定匿名可讀，授權(quán)后才可寫入    anon-access = read    auth-access = write    # 指定密碼文件為當(dāng)前目錄下passwd    password-db = passwdPasswd文件內(nèi)容如下，用戶名 = 密碼：    users    user1

5、= 123456     Subversion的Eclipse插件為：Subclipse，對SVN支持比較完善。一般的操作均可勝任。Subclipse和TortoiseSVN結(jié)合使用能發(fā)揮更大的威力。相關(guān)網(wǎng)站 SVN官方網(wǎng)站 TortoiseSVN，很好的SVN客戶端 SVN Service Wrapper SVN eclipse插件參考資料 中文的SVN資料http:/svnbook.red- Book: Version Control with SVN SVN for Windows中文安裝指南 SVN Book中文翻譯第一章 簡 介

6、60;   版本控制是管理信息變更的一門藝術(shù)。版本控制工具早已經(jīng)成為許多程序員的主要工具之一，特別是那些時常對軟件代碼作了微小的改動卻隔了一天就撤銷的程序員 們。但是版本控制軟件的用途并不僅限于軟件開發(fā)的領(lǐng)域。只要人們使用計算機來管理經(jīng)常變更的信息，就需要使用版本控制工具。而這正是 Subversion 可以展示自己的地方。    本章是對 Subversion 的一個概括性的介紹：Subversion 是什么？它用來做什么？以及如何得到它。第一章 簡 介    版本控制是管理信息變更的一門藝術(shù)。版本控制工具早已經(jīng)

7、成為許多程序員的主要工具之一，特別是那些時常對軟件代碼作了微小的改動卻隔了一天就撤銷的程序員 們。但是版本控制軟件的用途并不僅限于軟件開發(fā)的領(lǐng)域。只要人們使用計算機來管理經(jīng)常變更的信息，就需要使用版本控制工具。而這正是 Subversion 可以展示自己的地方。    本章是對 Subversion 的一個概括性的介紹：Subversion 是什么？它用來做什么？以及如何得到它。1.1 什么是 Subversion？    Subversion 是一個自由的、開放源碼的版本控制系統(tǒng)。也就是說，它可以管理各個時刻的文件和目錄。Subve

8、rsion 將文件存放在一個中心倉庫（repository）中。這個倉庫非常類似于一個普通的文件服務(wù)器，只是它還可以記錄文件和目錄曾經(jīng)做過的每一次變更。這 樣，我們就可以恢復(fù)舊版本中的數(shù)據(jù)或者是檢查數(shù)據(jù)曾經(jīng)做過怎樣的改動。在這點上，許多人都將版本控制系統(tǒng)比作一種"時間機器"。    Subversion 的倉庫可以通過網(wǎng)絡(luò)來訪問，允許不同的用戶在不同的計算機上使用。而使不同的使用者能夠在各自所在的位置修改和管理同一組數(shù)據(jù)將會在某種程度上促進協(xié)同工 作。由于不再將所有的修改工作都限制在一個"通道"上，項目的前進將更快速。而且因

9、為所作的工作都是被記錄的，如果做出了什么錯誤的修改，只需要撤銷就可 以了，而不用擔(dān)心失去那個"通道"將會同時失去質(zhì)量。    有些版本控制工具同時還是軟件配置管理系統(tǒng)（SCM,Software Configuration Management System）。這些系統(tǒng)是針對管理源代碼二設(shè)計的。它們有許多針對軟件開發(fā)的特性，例如本身就可以識別程序設(shè)計語言的語法，或者是提供編譯軟件的工具。 然而，Subversion 并不是這樣一個系統(tǒng)。它是一個通用的，可以管理任何計算機文件的系統(tǒng)。對你來說，可能是管理源代碼，而對其他人來說，從購物清單到視頻文件都

10、是可能的。1.2 Subversion 的歷史    在2000年年初，CollabNet公司（） 就開始尋找開發(fā)人員來設(shè)計一個用以替代 CVS 的系統(tǒng)。CollabNet 公司當(dāng)時正在提供一種叫做"SourceCast"的軟件協(xié)作開發(fā)套件。其中的一個組件就是版本控制系統(tǒng)。雖然該系統(tǒng)最初是使用 CVS 作為版本控制組件的，但是 CVS 的局限性從從始至終就很明顯。CollabNet 公司知道自己最終必須找到一個更好的替代品。但是很不幸，CVS 已經(jīng)成為了開放源碼領(lǐng)域中的事實上的標(biāo)準(zhǔn)。而很大一部分原因是因為找不到其他更好的系統(tǒng)。至少找不到更好的自

11、由軟件。于是，CollabNet 公司決定從頭設(shè)計一個版本控制系統(tǒng)。一個保留了 CVS 的基本思想，但是卻沒有缺陷的、有特色的版本控制系統(tǒng)。    2000年二月，他們聯(lián)系到了 Open Source Development with CVS 一書的作者 Karl Fogel。并且邀請其加入這個新項目。很巧合的是，那時 Karl 已經(jīng)和他的朋友 Jim Blandy 討論過一套新的版本控制系統(tǒng)的設(shè)計。在1995年，他們兩人曾經(jīng)開辦過一家公司 Cyclic Software。公司專門提供對 CVS 的支持服務(wù)。雖然他們后來賣掉了這項業(yè)務(wù)，但是仍然在每天的工作中使用

12、CVS 。在 CVS 上的挫敗讓 Jim 得以仔細的思考管理版本化數(shù)據(jù)的更好的方法。他不僅提出了"Subversion"的名字，同時還構(gòu)思了 Subversion 中心倉庫 Repository 的基礎(chǔ)設(shè)計思路。所以當(dāng) CollabNet 征招時，Karl 幾乎立刻就答應(yīng)了參加項目。Jim 的雇主：RedHat Software 贊助了該項目，并且是不限期的。CollabNet 雇用了 Karl 和 Ben Collins-Sussman。詳細的設(shè)計工作從當(dāng)年五月開始。這里我們應(yīng)該提到 CollabNet 的 Brian Behlendorf 和 Jason Robbins

13、 以及 Greg Stein （當(dāng)時是活躍于 WebDAV/DeltaV 規(guī)范進程的獨立開發(fā)者）。在他們的努力下，Subversion 很快就吸引了一批活躍的開發(fā)者。這正說明了許多人也曾在使用 CVS 中有過受挫折的經(jīng)歷。并且希望能夠改變這種局面。    最初的設(shè)計團隊決定了一些簡單的目標(biāo)。他們并不想在版本控制方法學(xué)中開辟新的天地，而是去修改 CVS。他們讓 Subversion 來使用 CVS 的特性，并且保留相同的開發(fā)模型。但是他們將避開 CVS 的那些明顯的缺陷。盡管 Subversion 并不需要設(shè)計的像一個 CVS 的潛移默化的替代品，它仍然應(yīng)該設(shè)計的與

14、 CVS 很像，以便于 CVS 的用戶可以毫不費力的切換過來。    在經(jīng)過十四個月的編碼之后，Subversion 于2001年8月進入"自測"階段。也就是說，Subversion 的開發(fā)者們停止使用 CVS 來管理 Subversion 的代碼，而取而代之的是 Subversion 自己。    當(dāng) CollabNet 啟動項目，并且資助很大一部分工作時（公司為一部分全職的開發(fā)人員支付薪水），Subversion 同時也像其他的開放源碼項目那樣運行。項目由一種鼓勵知識精英的松散的、透明的規(guī)則所支配。Collab

15、Net 的版權(quán)許可是完全遵從 Debian Free Software Guidelines 的。換句話說，任何人，如果他愿意的話，都可以自由的下載、修改和再次發(fā)行 Subversion；不需要從 CollabNet 或者任何人那里獲得授權(quán)。    1.3 Subversion 的特色    當(dāng)我們說起 Subversion 給版本控制系統(tǒng)領(lǐng)域帶來什么特色時，最好是說說它對 CVS 的設(shè)計所作的改進。如果你不熟悉 CVS 的話，你可能不理解這里的某些特性。如果你對版本控制也不了解，最好去閱讀一下第二章：基本概念。在第二章我們給出了對版

16、本控制的一般性的介紹。    Subversion 的特性：    目錄控制        CVS 只能跟蹤單個文件的歷史，而 Subversion 實現(xiàn)了一個"虛擬"的受控文件系統(tǒng)，可以跟蹤整個目錄的變更。    真正的版本歷史        由于 CVS 只限于記錄文件的版本信息，像文件復(fù)制、重命名這樣的操作它就不支持了。而這些操作是會實實在在

17、發(fā)生的，它們改變了所對應(yīng)目錄的內(nèi)容。另外，在 CVS 中，如果你要用一個新文件來替換一個舊文件，并且兩個文件名稱相同的話，新文件將不得不繼承舊文件的歷史信息。即使是兩個文件毫不相干也是這樣。而在 Subversion 中，我們可以添加、刪除、復(fù)制和重命名文件和目錄。每一個新添加的文件都將擁有它自己的全新的歷史信息。    原子化提交        一個變更集要么完整地被提交到倉庫中，要么不做任何改變。這就允許開發(fā)人員把構(gòu)造和提交修改當(dāng)作一個邏輯上的整體來看。從而避免發(fā)生不完整地提交變更的情況。&

18、#160;   受控元數(shù)據(jù)        每一個文件和目錄都有一個與其對應(yīng)的屬性集。你可以創(chuàng)建和保存任何"鍵名/鍵值"對來輔助文件本身。而這些屬性就像文件內(nèi)容一樣，也是受版本控制系統(tǒng)控制的。    可選的網(wǎng)絡(luò)層        Subversion 倉庫的存取是一個抽象概念，有利于其他人實現(xiàn)新的網(wǎng)絡(luò)訪問機制。Subversion 可以作為一個外部模塊插入到 Apache HTTP 服務(wù)器中

19、。這帶給它在穩(wěn)定性和互操作性方面的巨大優(yōu)勢。并且，Subversion 可以方便的利用 Apache 所提供的功能身份認(rèn)證、權(quán)限管理、數(shù)據(jù)壓縮等等。還有一個更輕量級的、單獨的 Subversion 服務(wù)器叫做 Subversion server process。它引入了一種自定義的協(xié)議，可以很容易的使用 SSH 來建立通道。    一致的數(shù)據(jù)處理        Subversion 使用一種二進制的比較算法來表示文件之間的區(qū)別。它在文本文件（可閱讀的）和二進制文件（不可閱讀的）上是沒有區(qū)別的。兩

20、種類型的文件經(jīng)過壓縮后都同樣的存放在倉庫中，唯一的不同就是在網(wǎng)絡(luò)上傳輸時的方法。    高效的分支和標(biāo)記        分支和標(biāo)記所帶來的開銷與項目的規(guī)模并沒有直接的關(guān)系。Subversion 在創(chuàng)建分支和標(biāo)記時使用類似"連接"的方式來復(fù)制項目。這樣這些操作就只會耗費很少的通常是一個固定長度的時間。    擴展能力        Subversion 沒有什么歷史包袱；它是由一

21、組設(shè)計良好的 APIs實現(xiàn)的，包含在 C 的共享庫中。這使得它很容易維護。也很容易被其他應(yīng)用程序或語言使用。1.4 Subversion 的結(jié)構(gòu)    圖1.1，"Subversion 結(jié)構(gòu)"描述了 Subversion 的一個很粗略的設(shè)計思路。    在系統(tǒng)的一端是存放著所有受控制數(shù)據(jù)的 Subversion 倉庫。另一端是 Subversion 的客戶端程序，管理著受控數(shù)據(jù)的一部分在本地的映射（稱為"工作副本"）。在這兩端之間，是通過各種倉庫存取層（Repository Access,RA）

22、的多條通道。這些通道中，有些要使用計算機網(wǎng)絡(luò)，再通過用來訪問 Subversion 倉庫的服務(wù)器。而有些則完全繞過了網(wǎng)絡(luò)，直接對倉庫進行操作。1.5 安裝 Subversion    Subversion 是建立在一個叫做 APR（the Apache Portable Runtime library）的可移植運行庫之上的。這也就是說，Subversion 可以運行在任何 Apache 服務(wù)器可以運行的操作系統(tǒng)之上：Windows、Linux，各種類型的 BSD、Mac OS X，Netware 以及其他的系統(tǒng)。    獲得 Subv

23、ersion 的最簡單的方法就是下載適合于你的操作系統(tǒng)的二進制軟件包。Subversion 的站點（）一般會有這樣的下載連接。通常來說，使用 Microsoft 操作系統(tǒng)的用戶都可以得到有圖形界面的安裝程序。如果你使用的是類似 Unix 的操作系統(tǒng)的話，可以使用合適的打包分發(fā)系統(tǒng)（RPMs,DEBs,the ports tree等等）來獲取。    同時，我們也可以直接使用源代碼來編譯 Subversion 。首先從它的官方站點下載最新的源代碼發(fā)布。然后將其解壓縮，按照 INSTALL 文件中的指示來編譯系統(tǒng)。值得注意的是，一個發(fā)行版的源代碼包中包含了許多工具，足

24、夠你編譯出一個可以和遠程倉庫連接的命令行工具（一般來說，有 apr、apr-util和一個初始的庫）。但是 Subversion 中一些可選的部分則需要許多其他軟件支持，例如 Berkeley DB 或者 Apache 。如果你要編譯一個完全的系統(tǒng)的話，必須保證擁有 INSTALL 文件中提到的所有的軟件包。而如果你想使用 Subversion 本身來獲取代碼的話，可以用你的客戶端程序來得到最實時的源代碼。在"獲取源代碼"一節(jié)中，我們將詳細介紹有關(guān)情況。1.6 Subversion 的組件    一旦 Subversion 成功安裝，我們將會看

25、到多個不同的應(yīng)用程序。下面我們就來大致的看一下都有些什么組件。如果下面的這些簡要說明讓您感到迷惑的話，請先別著急。這本書還有許多頁是專門為您消除這些困惑的。    svn        一個命令行式的客戶端程序；    svnversion        報告本地工作副本狀態(tài)（用當(dāng)前檔案的修訂版本號表示）的程序；    svnadmin  

26、0;     用來創(chuàng)建、tweaking或者是修復(fù)倉庫的工具；    svndumpfilter        A program for filtering Subversion repository dumpfile format streams.    mod_dav_svn        Apache 服務(wù)器的一個插件模塊，用來使其他人可以通過網(wǎng)絡(luò)訪

27、問這個倉庫；    svnserve        一個定制的、獨立的 Subversion 服務(wù)程序?？勺鳛橐粋€駐留進程運行或者是由 SSH 調(diào)用。是使倉庫可以被別人通過網(wǎng)絡(luò)訪問的另一種方法。    假如你正確的安裝了 Subversion ，你應(yīng)該可以開始使用了。接下來的兩章將為你介紹 Subversion 的命令行工具 svn 的使用。1.7 快速入門    在我們當(dāng)中，可能有些人不是很習(xí)慣從頭到尾的閱讀一本書來吸收新技術(shù)的方式。

28、這一節(jié)，我們將先行給出一個 Subversion 的使用介紹。心急的讀者可以有機會通過實踐來學(xué)習(xí)使用 Subversion 的技巧。同時，我們會告訴你到哪一章節(jié)可以找到相關(guān)的東西。    如果你對版本控制的整體概念很生疏，或者對 CVS 和 Subversion 使用的"復(fù)制修改合并"模型不熟悉的話，最好在往下讀之前先去仔細看一下第二章基本概念。    注意：        在運行下面的例子之前，你必須保證下面兩個工具可以正確運行： &

29、#160;          svn      命令行式的客戶端程序；            svnadmin 管理工具；        同時還必須保證你的 svn 工具是針對 Berkeley DB 編譯的?？梢赃\行 svn -version 然后檢查 ra_local 模塊是

30、否可用來確認(rèn)。如果沒有這個模塊，我們的客戶端程序?qū)o法訪問 。    Subversion 將所有控制的數(shù)據(jù)都放在一個中央倉庫中。所以首先，我們要創(chuàng)建一個這樣的倉庫：        $ svnadmin create /path/to/repos        $ ls /path/to/repos          conf/ 

31、; dav/  db/  format  hooks/  locks/  README.txt    這個命令創(chuàng)建了一個包含 Subversion 倉庫的目錄 /path/to/repos 。另外，這個目錄必須創(chuàng)建在本地磁盤，而不能是在網(wǎng)絡(luò)共享磁盤上。該目錄主要包含了一些 Berkeley DB 的文件。在這個目錄中，你是找不到所保存的文件的。在第五章倉庫管理中可以找到更多的有關(guān)于倉庫創(chuàng)建和維護的知識。    下一步，準(zhǔn)備一個類似下面例子中的用來導(dǎo)入的文件、目錄樹。在樹結(jié)構(gòu)中，應(yīng)該包含

32、三個頂層目錄：branches、tags 和 trunk。具體的原因后面便會清楚了（參見第四章分支和合并）。        /tmp/project/branches/        /tmp/project/tags/        /tmp/project/trunk/         

33、0;              foo.c                        bar.c           

34、0;            Makefile                        .    一旦你準(zhǔn)備好了目錄樹，就可以使用 svn import 命令來導(dǎo)入數(shù)據(jù)到倉庫中了（參見"svn import"

35、;一節(jié)）：        $ svn import /tmp/project file:/path/to/repos -m "initial import"        Adding /tmp/project/branches        Adding /tmp/project/tags      

36、60; Adding /tmp/project/trunk        Adding /tmp/project/trunk/foo.c        Adding /tmp/project/trunk/bar.c        Adding /tmp/project/trunk/Makefile        .&#

37、160;       Committed revision 1.        $    現(xiàn)在，倉庫中就有了整個目錄樹中的數(shù)據(jù)。注意，原始的 /tmp/project 目錄并沒有變化，Subversion 并不使用它。（實際上，如果你愿意的話，可以刪除該目錄）。為了開始操作倉庫中的數(shù)據(jù)，我們需要先創(chuàng)建一個數(shù)據(jù)的"工作副本（working copy）"出來。這類似于一種私有的工作區(qū)。向 Subversion "

38、;check out"（借出）一份倉庫中 trunk 目錄的工作副本：        $ svn checkout file:/path/to/repos/trunk project        A  project/foo.c        A  project/bar.c       

39、; A  project/Makefile        .        Checked out revision 1.    現(xiàn)在，我們在一個新的 project 目錄下就有了倉庫中一部分?jǐn)?shù)據(jù)的一個私人副本了。你可以在本地工作副本上編輯某個文件，然后再將那些修改提交到倉庫中。        ?進入工作副本目錄，修改文件內(nèi)容； 

40、0;      ?運行 svn diff 來檢查你對文件的修改情況；        ?運行 svn commit 來將新版本的文件提交到倉庫中；        ?運行 svn update 來使用倉庫中最新的版本來更新你的本地工作副本。    如果想知道我們可以對"本地工作副本"所作的事情，請參閱第三章使用指南。    這時，你

41、可以選擇是否讓其他人通過網(wǎng)絡(luò)訪問你的倉庫。你可以閱讀第六章服務(wù)器配置來學(xué)習(xí)不同的服務(wù)器程序和如何配置它們第二章 基本概念    本章是對 Subversion 的一個簡短的介紹。如果你是使用版本控制工具的新手，這一章將非常適合你。我們先從版本控制的一般概念說起，接著會談到 Subversion 底層的具體思想以及一些簡單的案例。    盡管在本章的案例中我們展示的是如何協(xié)同管理軟件源代碼，但請記住，Subversion 可以管理任何類型的文件集合，而并不僅限于源程序。第二章 基本概念    本章是對 Su

42、bversion 的一個簡短的介紹。如果你是使用版本控制工具的新手，這一章將非常適合你。我們先從版本控制的一般概念說起，接著會談到 Subversion 底層的具體思想以及一些簡單的案例。    盡管在本章的案例中我們展示的是如何協(xié)同管理軟件源代碼，但請記住，Subversion 可以管理任何類型的文件集合，而并不僅限于源程序。2.1 倉庫（The Repository）    Subversion 是一個集中式的系統(tǒng)。它的核心是一個用來存放數(shù)據(jù)的中心倉庫。中心倉庫使用典型的文件和目錄層次結(jié)構(gòu)樹狀結(jié)構(gòu)來存儲信息。許許多多的客戶端可以連

43、接到 中心倉庫，然后讀取或者寫入文件?？蛻舳送ㄟ^寫文件來使其他人共享，也可以讀取其它客戶端所寫入的文件。下面的圖2.1描述了這樣的一個典型的客戶端/服 務(wù)器系統(tǒng)模型。               圖2.1    有趣的是，到此為止，這個倉庫聽起來像是一個典型的文件服務(wù)器。而且確實，倉庫就是一種文件服務(wù)器，只是不是通常的那種。Subversion 倉庫可以記錄寫入倉庫的每一次更改。這些更改包括對每一個文件的每一次修改，甚至是對目

44、錄本身的修改，例如添加文件、刪除文件和對文件和目錄的重新編排。 這些特性使得 Subversion 倉庫與一般的文件服務(wù)器相比較為特殊。    當(dāng)一個客戶端讀取倉庫中的數(shù)據(jù)時，他通常只能看到最新版本的文件目錄。但是客戶端同樣可以讀取文件和目錄以前某個時刻的狀態(tài)。例如，客戶端可以這樣做查 詢："上個星期三這個目錄包含什么文件？"或者是"修改這個文件的最后一個人是誰？他做了什么修改？"。這類問題正是版本控制系統(tǒng)的核心：記錄和跟蹤數(shù)據(jù) 的修改歷史。2.2 版本控制模型    版本控制系統(tǒng)的核心任務(wù)是使

45、得數(shù)據(jù)可以協(xié)作處理和共享。但是不同的系統(tǒng)使用不同的策略來達到這個目標(biāo)。 文件共享的問題    所有的版本控制系統(tǒng)都必須解決一個共同的基本問題：如何讓用戶來共享信息，并且還要避免他們不小心覆蓋掉別人對倉庫中數(shù)據(jù)作過的修改？畢竟，這種情況太容易發(fā)生了。    讓我們先來看看下面的圖2.2 "要避免的問題"。假設(shè)我們有兩個合作開發(fā)者：Harry 和 Sally。他們兩個人在同一個時間決定對倉庫中的同一個文件進行編輯。如果 Harry 先將他的修改保存到倉庫中，那么可能在很短時間之后，Sally 會使用她的新版本文件覆蓋掉

46、倉庫中該文件。由于系統(tǒng)記錄了 Harry 對文件的修改，但是這些修改并沒有出現(xiàn)在 Sally 的新版本文件中。這樣，Harry 的工作實際上就丟掉了，或者說在最新版本的文件中漏掉了。這是我們一定要避免出現(xiàn)的情景。    圖2.2 要避免的問題 "鎖定修改解鎖" 方案    許多版本控制系統(tǒng)都使用"鎖定修改解鎖"模型來解決這個問題。在這樣一個系統(tǒng)中，倉庫在一個特定的時刻只允許一個人對某個文件進行修改。首先， Harry 必須在修改文件之前"鎖定"它。鎖定一個文件很像是從圖書館借

47、出一本書；如果 Harry 鎖定了一個文件，那么 Sally 就不能對那個文件作任何修改了。如果 Sally 也試圖鎖定這個文件，倉庫將禁止這項操作。她只能讀取該文件，然后等待 Harry 完成他的修改并解鎖文件。在 Harry 解鎖那個文件之后，他的回合就結(jié)束了。這是輪到 Sally 來鎖定和編輯文件。圖2.3 簡單的演示了這種方案。    圖2.3 "鎖定修改解鎖"方案    這種方案的問題是它有一點過于嚴(yán)格了，經(jīng)常會阻塞用戶的使用：    ?鎖定可能會帶來管理問題。有時 Harr

48、y 鎖定了一個文件，但是隨后卻忘了這回事。同時，Sally 的任務(wù)卻因為仍然在等待編輯那個文件而停滯不前?，F(xiàn)在，Harry 去休假了。Sally 只能是去找管理員來釋放 Harry 對這個文件的鎖定。這種情況最終導(dǎo)致了項目不必要的延遲和寶貴時間的浪費。    ?鎖定可能導(dǎo)致不必要的串行工作。如果 Harry 要編輯一個文本文件的開頭部分，而 Sally 只想編輯同一個文件的結(jié)尾部分，這些更改根本不會重疊和沖突。假設(shè)他們的修改可以很好的合并在一起，他們本可以同時對文件進行修改，而不會引起大的混亂。 這種情況下并沒有必要非得一個一個的串行工作。  

49、  ?鎖定可能會引起潛在的不安全性。假如，Harry 鎖定了文件 A 進行編輯，而同時，Sally 則鎖定了文件 B 進行編輯。但是假設(shè)文件 A 和 B 是互相依賴的兩個文件，兩人在兩個文件上所作的改動是不兼容的。一下子，A 和 B 同時都不能工作了。鎖定機制很難解決這個問題。Harry 和 Sally 很容易在鎖定文件后就主觀的認(rèn)為已經(jīng)獲得了一個安全的、隔絕的任務(wù)，這樣就導(dǎo)致了他們不可能盡早地討論文件修改的兼容性問題。 "復(fù)制修改合并"方案    Subversion、CVS以及其他一些版本控制系統(tǒng)使用"復(fù)制修改合并&qu

50、ot;模型來代替鎖定。在這種模型中，每一個用戶的客戶端軟件從中央倉庫創(chuàng)建出 一份個人的工作副本倉庫中文件和目錄的本地映射。之后，用戶就可以并行工作，修改手中的私有副本。最后，這些私有副本合并成為一個全新的版本。版本控 制系統(tǒng)常常需要合并，但是最終，操作者本身必須負(fù)責(zé)讓合并工作正確進行。    這里有一個例子。Harry 和 Sally 都從倉庫中復(fù)制出一份同一個項目的工作副本。他們同步工作，并且同時對工作副本中的同一個文件 A 作修改。Sally 先將她的修改保存到倉庫中。當(dāng) Harry 也準(zhǔn)備保存他的修改時，倉庫會提示說他的文件是"過時"的。

51、換句話說，在他最后復(fù)制文件 A 之后，文件 A 不知何時已經(jīng)發(fā)生了變化。所以，Harry 要求他的客戶端將倉庫中的新的變化"合并"到他的工作副本中。很有可能，Sally 的修改并沒有覆蓋掉他所作的工作。這樣，一旦他將兩部分修改集成到一起，Harry 就可以將他的工作副本保存到倉庫中。圖2.4 "復(fù)制修改合并方案"和圖2.5 "復(fù)制修改合并方案（續(xù)）"描述了這個過程。    圖2.4 "復(fù)制修改合并方案"    圖2.5 "復(fù)制修改合并方案（續(xù)）&

52、quot;    但是，如果 Sally 的修改會覆蓋掉 Harry 的工作怎么辦？這種情況叫做"沖突（conflict）"，卻也稱不上是什么問題。當(dāng) Harry 要求他的客戶端軟件合并倉庫中的最新修改到工作副本時，文件 A 被標(biāo)記為沖突狀態(tài)。這時，他可以看到相互沖突的兩份修改，并且手動選擇如何處理。注意，軟件并不能自動解決沖突。只有人本身才有能力理解和做出合理的選 擇。一旦 Harry 手動解決了那些可能導(dǎo)致覆蓋的修改（也許這個過程中需要和 Sally 協(xié)商一下），他就可以安全地將合并后的文件保存到倉庫中了。   

53、; 復(fù)制修改合并模型也許聽起來有一點混亂，但是實際上，它工作地非常的穩(wěn)定。用戶可以并行工作，完全不需要等待其他人。當(dāng)他們在同一個文件上工作時，其實大多數(shù)的并行修改都不會覆蓋對方，沖突不會常常發(fā)生。用于解決沖突的時間遠遠少于鎖定系統(tǒng)所帶來的時間浪費。    最終，我們將所有的問題歸結(jié)為一個關(guān)鍵因素：用戶交流。如果用戶很少交流，不論是語法的還是語義的沖突都會增加。沒有哪個系統(tǒng)可以讓用戶完美地交流，也沒 有哪個系統(tǒng)可以自動檢查出語義上的沖突。所以，不要被那種鎖定系統(tǒng)可以解決沖突的虛假承諾所麻痹，事實上，鎖定系統(tǒng)除了限制生產(chǎn)力之外一無是處。2.3 實際中的 Subvers

54、ion    現(xiàn)在是讓我們從抽象概念過渡到具體實踐的時候了。在這一節(jié)中，我們會演示一個真實的例子。    工作副本    在上文中，我們已經(jīng)知道了工作副本這個概念了。在這里，我們來演示一下如何使用 Subversion 的客戶端來創(chuàng)建和使用工作副本。    一個 Subversion 的工作副本其實就是本地系統(tǒng)中的一個普通的文件目錄樹。你可以使用任何方式來編輯這些文件。如果是源代碼文件的話，你也可以像通常情況那樣去編譯它們。工 作副本是你的私人工作區(qū)。如果你不明確的要求，Su

55、bversion 絕不會合并其他人的修改，也不會讓其他人看到你做的修改。    在你已經(jīng)修改完工作副本中的文件，并且確信修改正確后，就可以將這些修改公開給同一個項目中的其他工作人員。Subversion 提供了將文件寫入倉庫的命令。通過這種方式來達到公布你的修改的目的。如果其他人公布了他們的修改，也可以使用 Subversion 提供的命令來合并修改（通過從倉庫中讀出文件）。    工作副本中也包含一些額外的文件。它們是由 Subversion 創(chuàng)建和維護的，用來輔助完成這些命令。最典型的情況是，每一個目錄都包含一個叫做 .svn 的

56、子目錄。該目錄也被稱為"工作副本管理目錄"。在管理目錄中的那些文件可以幫助 Subversion 來識別哪些文件包含沒有發(fā)布的修改，以及哪些文件已經(jīng)過期了。    通常，一個 Subversion 的倉庫會包含幾個項目，而每一個項目都是倉庫的目錄的一個子目錄。這樣，用戶的工作副本也就對應(yīng)于倉庫中一個特定的子目錄。    例如，假設(shè)我們有一個包含兩個軟件項目的倉庫。它們分別叫做 paint 和 calc。每一個項目都在它們自己的頂層子目錄下。如圖2.6 "倉庫的文件系統(tǒng)"所示。 

57、0;  圖2.6 "倉庫的文件系統(tǒng)"    為了獲得一份工作副本，我們必須先"check out"倉庫中的某一個子目錄。（check out 這個詞聽起來有點像是要鎖定什么資源，但事實上不是，它只是簡單的創(chuàng)建一份工作副本而已）。例如，我們來 check out 一個 /calc 項目的工作副本：    $ svn checkout     A  calc    A  calc/Makefile &

58、#160;  A  calc/integer.c    A  calc/button.c    $ ls -A calc    Makefile  integer.c  button.c  .svn/    上面以字母 A 開頭的行表明了 Subversion 已經(jīng)為我們的工作副本添加了一些東西?，F(xiàn)在，我們擁有了倉庫中 /calc 目錄的一份私有副本。另外還有一個額外的目錄 .svn 用來保存 Subversion

59、需要使用的額外信息。我們前面已經(jīng)提到過它了。    （開始）    Repository URLs    Subversion 的倉庫可以通過多種方式來訪問，例如本地磁盤或者是網(wǎng)絡(luò)協(xié)議。然而，一個倉庫的位置總是以 URL 的方式出現(xiàn)。表2-1描述了不同的訪問方法所對應(yīng)的 URL 樣式。    表2-1 倉庫存取 URLs        樣式      

60、60;          存取方式     file:/              直接從本地磁盤上訪問倉庫     http:/              

61、通過 WebDAV 協(xié)議訪問 Apache 服務(wù)器，進而訪問倉庫     https:/              和 http:/ 相同，但使用 SSL 來作加密     svn:/                通過自定義的協(xié)議訪問一個

62、 svnserve 服務(wù)器     svn+ssh:/            和 svn:/ 相同，但通過一個 SSH 通道來使用    很多情況下，Subversion 的 URLs 都使用標(biāo)準(zhǔn)的語法，并允許在 URL 中使用服務(wù)器名稱和端口號。記住， file:/ 方式只在本地服務(wù)器上有效。也就是說客戶端和服務(wù)器在同一臺機器上的情況。事實上，按照慣例，在 URL 中的服務(wù)器名稱必須是空的或者是 localhost

63、：    $ svn checkout file:/path/to/repos    .    $ svn checkout file:/localhost/path/to/repos    .    同樣，在 Windows 平臺上使用 file:/ 方式時，也需要使用一種非官方的"標(biāo)準(zhǔn)語法"來存取本地的倉庫。除非是倉庫和客戶端不在同一個驅(qū)動器上。下面兩種 URL 語法都可以正確工作。假設(shè) X 是倉庫所在的驅(qū)動器。 

64、;   C:> svn checkout file:/X:/path/to/repos    .    C:> svn checkout "file:/X|/path/to/repos"    .    在第二種語法中，你必須使用引號來標(biāo)記一下，以防止 '|' 被當(dāng)作管道命令。    注意：這里的 URL 使用斜杠 '/' 而不是反斜杠 '' 。&

65、#160;   （結(jié)束）    假設(shè)你對 button.c 文件作了修改。由于 .svn 目錄中記錄了文件的修改日期和原始內(nèi)容，Subversion 可以指出你已經(jīng)修改了文件。但是，如果你不明確聲明，Subversion 不會自作主張去把這些修改發(fā)布。發(fā)布修改的動作通常叫做"提交"（committing or checking in）修改到倉庫。    你可以使用 Subversion 的 commit 命令來發(fā)布修改：    $ svn commit button

66、.c    Sending        button.c    Transmitting file data .    Committed revision 57.    這樣，你對 button.c 文件的修改就提交到倉庫了；如果其他用戶 check out 了一份 /calc 的工作副本，他們就會在最新版本的文件里看到你做的修改了。    假如你有一個協(xié)作開發(fā)者 Sall

67、y 。她和你同時 check out 了 /calc 目錄的工作副本。當(dāng)你提交你對 button.c 的修改后，Sally 的工作副本就變成了舊的了；Subversion 只有在用戶請求時才會更新本地工作副本。    如果 Sally 想讓她的項目保持更新，她可以使用 update 命令來請求 Subversion 更新她的本地工作副本。這樣，你的修改將會合并到她的工作副本，當(dāng)然還有在她簽出（check out）期間其他人所作的修改。    $ pwd    /home/sally/calc &

68、#160;  $ ls -A    .svn/    Makefile    integer.c    button.c    $ svn update    U button.c    執(zhí)行 svn update 時候的輸出內(nèi)容表明 Subversion 更新了 button.c 的內(nèi)容。Sally 并不需要指定更新哪個文件；Subversion 根據(jù) .svn 目錄以及倉庫

69、中的信息來決定哪些文件將被更新。 修訂本    一個 svn commit 操作可以將任意數(shù)量的文件和目錄的修改發(fā)布作為一個單獨的原子事務(wù)來處理。在你的工作副本中，你可以修改文件內(nèi)容，創(chuàng)建、刪除、重命名以及復(fù)制文件和目錄，然后作為一個單獨的單元來提交所有這些修改。    在倉庫中，每一次提交都被作為一個原子事務(wù)來對待：要么所有的提交都成功執(zhí)行，要么什么都不發(fā)生。Subversion 試圖在面對程序崩潰、系統(tǒng)崩潰、網(wǎng)絡(luò)問題和其他用戶的動作時保留這種原子性。    每當(dāng)倉庫接受一次提交，倉庫中的文件系統(tǒng)目錄都

70、會創(chuàng)建一種新的狀態(tài)，叫做一個修訂本。每一個修訂本都被賦予一個唯一的自然數(shù)，并且每一個修訂本的數(shù)字都比前一個要大。剛剛建立的倉庫的初始的版本是 0 ，只包含一個空的根目錄。    圖2.7 "倉庫"是一個倉庫的想象圖。設(shè)想一個修訂版編號的數(shù)列，從 0 開始，從左延伸到右。每一個修訂版編號都對應(yīng)一個畫下面的目錄樹，而每一個目錄樹就是在每一次提交之后的倉庫的"快照"。    圖2.7    （表格開始）    全局修訂本編號： &#

71、160;  Subversion 的修訂版編號是針對整個目錄樹的，而不是某一個獨立的文件。這與其他許多的版本控制系統(tǒng)不同。每一個修訂版編號都代表了倉庫中一個樹在某次提交后的一個特 定狀態(tài)。從另一個角度來講，修訂版 N 表示經(jīng)過了 N 提交之后的倉庫目錄樹。如果某人說"文件 foo.c 的 revision 5"，那么應(yīng)該理解為"在項目的 revision 5 中看到的 foo.c 文件"。值得注意的事，通常 revisions N 和 revisions M 的某個文件并不一定非得是不同的。由于 CVS 使用每一個文件一個修訂版編號的方式，CV

72、S 的用戶請閱讀附錄A Subversion for CVS Users。    （表格結(jié)束）    有一點非常重要，工作副本并不總是對應(yīng)于倉庫中一個單一的修訂版，有時可能會包含幾個其他修訂版的文件。舉個例子來說，假設(shè)你 check out 了一個倉庫中的項目，修訂版編號是 4 ：    calc/Makefile:  4        integer.c:  4    

73、60;   button.c:  4    此時，這份工作副本之對應(yīng)于修訂版4。然而，如果你對 button.c 做了修改，并且提交了修改。如果沒有其他人提交其他修改的話，你的這個動作會創(chuàng)建倉庫中項目的另一個修訂版編號：5，而你的工作副本將會是這樣：    calc/Makefile:  4        integer.c:  4       

74、button.c:  5    假設(shè)這個時候，Sally 提交了她對 integer.c 的修改，創(chuàng)建了修訂版 6。如果你使用 svn update 命令來更新工作副本，則會看到：    calc/Makefile:  6        integer.c:  6        button.c:  6    Sally 的修改

75、會出現(xiàn)在你的本地工作副本中，而你的修改也仍然在 button.c 中。在這個例子里，文本文件 Makefile 在修訂版4、5、6中是一樣的，但是 Subversion 還是會把 Makefile 的本地工作副本標(biāo)示為 revision 6 來表示它是最新的。所以，當(dāng)你對你的工作副本做過一次更新之后，它將只對應(yīng)倉庫中"一個"修訂版。 工作副本如何跟蹤倉庫    對于工作副本中的每一文件，Subversion 在 .svn/ 管理區(qū)中保存兩條必需的信息：    ?這個工作文件的修訂版編號（也叫做文件的"工作

76、版本"）；    ?本地副本最后一次更新的時間戳。    基于這些信息，Subversion 通過和倉庫來通訊，可以報告一個工作文件處于下面四種狀態(tài)中的哪一種：        未改變的，并且是最新的            文件沒有在工作副本中修改過，而且也沒有人向倉庫提交過修改。對此文件執(zhí)行 svn commit 或是 svn update 是無效的。        在本地修改過，是最新的            文件在工作副本中修改過，沒有其他人提交過目前修訂版的修改。這時，可以執(zhí)行 svn commit 來提交修改。而執(zhí)行 svn update 是無效的。        未改變的，但是過時的