TortoiseSVN客戶端常用命令詳解

1、TortoiseSVN客戶端常用命令詳解TortoiseSVN客戶端常用命令詳解1、Checkout 首先要Checkout服務(wù)器端的Repository， 所謂的Checkout就是指獲得服務(wù)器端指定的Repository存儲的所有文件。Checkout的具體方式是： 在客戶端新建一個空目錄，比如：F:Project1 （確保是空的） 在該目錄上單擊右鍵，在彈出式菜單中選中SVN Checkout.， 之后按要求錄入內(nèi)容： 然后點(diǎn)OK，會彈出一個認(rèn)證對話框， 輸入用戶名和密碼。點(diǎn)OK后就完成了對Repository的Checkout。檢出后，所有檢出文件上都打著綠色對勾： 命令方式檢出1：在

2、DOS命令中輸入需要檢出的目錄：10:8081/svn/svnproject/Knowledge2：其中，意思是，檢出文檔是放在D盤的根目錄下，是檢出文檔的存放位置，如下圖：2、update獲取版本庫中最新版本，具體的方法是：在WC目錄上單擊右鍵，SVN Update。這時(shí)WC中的文件就是最新的版本了。3、commitcommit功能就是將你本地的文件修改記錄上傳到服務(wù)器上面，可以理解為上傳。只會上傳原先checkout然后又被修改了的文件，假如你新加入了某些文件，需要右鍵點(diǎn)擊文件選擇Add，然后文件上面會出現(xiàn)一個加號，在下次commit的時(shí)候才能選到該文件。

3、commit頁面：注意：commit的時(shí)候，最好填寫Log信息，Log內(nèi)容包括：修改了哪些東西及為什么做這些修改（what+why）強(qiáng)制必須錄入log: property 中設(shè)置錄入log最小長度，此時(shí)commit必須錄入log,否則不允許提交.設(shè)置錄入log最小長度頁面：4、add將要添加的文件或者目錄拷貝到WC下， 然后在該文件或目錄上單擊右鍵，TortoiseSVN->Add，點(diǎn)OK。 如果添加了不止一個文件或目錄， 則鼠標(biāo)不要在WC中點(diǎn)中任何文件， 然后單擊右鍵，TortoiseSVN->Add， 就可以添加多個文件或目錄。 這時(shí)文件的狀態(tài)圖標(biāo)會發(fā)生如下變化： Add命令只

4、是告訴本地的WC將該文件納入版本管理， 并沒有將這個改變提交到服務(wù)器端， 在F:Project1下單擊右鍵，SVN Commit.， 將你所做的修改提交到Repository。5、modify 用文本編輯器或IDE對文件修改后， 文件的狀態(tài)圖標(biāo)會變化， 然后單擊右鍵，SVN Commit. 即可提交修改。6、revert（1）、放棄未提交的修改， 單擊右鍵，TortoiseSVN->Revert， 本地的WC中的文件和目錄會恢復(fù)到修改前的狀態(tài)。（2）、回復(fù)到之前某個revision狀態(tài)： a、 在本地WC中單擊右鍵，TortoiseSVN->Update to Revision.，

5、 然后輸入你想要回復(fù)到的Revision號點(diǎn)OK按鈕。此時(shí)僅僅是WC中回復(fù)到特定版本，對Repository沒有任何影響。 b、把Repository回復(fù)到某個revision狀態(tài)方法：方法一： 先執(zhí)行Update命令將Working Copy更新到最新的Revision， 然后在Working Copy中單擊右鍵， TortoiseSVN->Show Log， 彈出的Log Messages窗口中會顯示該Repository的所有Revision， 選中最新的Revision，之后按住Shift鍵， 再單擊你想回復(fù)到的Revision+1的那個Revision （比如Repositor

6、y的最新Revision是79， 你想將Repository的狀態(tài)回復(fù)到Revision60， 那么就選中Revision70，再按住Shift鍵， 選中Revision61， 就是說選中Revision61到Revision79之間的所有Revision）。 然后在選中的Revision上單擊右鍵， 選中“Revert changes from these revision”。 再點(diǎn)Yes按鈕，就可以將WC的狀態(tài)回復(fù)到目標(biāo)Revision60。 注意：此時(shí)只是WC回復(fù)到目標(biāo)Revision，之后應(yīng)該用Commit提交修改， 這樣Repository最新狀態(tài)就與WC的狀態(tài)一致，都為 Revis

7、ion60。方法二：采取大版本號向小版本號merge的方式，進(jìn)行回滾 保證我們拿到的是最新代碼，TortoiseSVN右鍵àmerge,如果我們最新版本為79，要回滾到60，如下圖，“From”的URL和“to”的URL均了錄入要回復(fù)的文件在版本庫的存放地址  點(diǎn)“merge”,然后commit即可。7、delete 刪除文件時(shí)，選中要刪除的文件或目錄， 單擊右鍵，TortoiseSVN->Delete然后提交修改。注意千萬不要用windows自己的“刪除”或者“Delete”鍵來刪除文件，否則將無法提交你的修改。 這一點(diǎn)對目錄的刪除來說尤為重要。

8、 因?yàn)槊總€目錄里有個 .svn隱藏目錄 ，存放目錄下文件的信息，使用操作系統(tǒng)命令delete/move時(shí)， .svn還指向原來的位置，所作操作不受SVN控制。8、move移動方法：(1)、選擇你要移動的文件或目錄(2)、拖拽(right-drag)他們到新的工作副本下，(3)、松開鼠標(biāo)右鍵(4)、在彈出菜單選擇上下文菜單 SVN 移動文件。 原理同上。9、Branche/Tag 操作方法：創(chuàng)建分支非常簡單，只需在需要創(chuàng)建分支的工作目錄上，使用TortoiseSVN Branch/Tag命令，在 "To URL" 項(xiàng)指定待創(chuàng)建的分支 url 即可實(shí)現(xiàn)本質(zhì)：subversion

9、對分支和標(biāo)簽是通過復(fù)制一份最新的版本庫的快照來實(shí)現(xiàn)的。一般情況下，tag，是用來做一個milestone的，不管是不是release，都是一個可用的版本。這里應(yīng)該是只讀的,更多的是一個顯示用的，給人一個可讀（readable）的標(biāo)記；branch，是用來做并行開發(fā)的，這里的并行是指和trunk進(jìn)行比較。分支與標(biāo)簽的區(qū)別：在實(shí)現(xiàn)上，branch和tag，對于svn都是使用copy實(shí)現(xiàn)的，所以他們在默認(rèn)的權(quán)限上和一般的目錄沒有區(qū)別。至于何時(shí)用tag，何時(shí)用branch，完全由人主觀的根據(jù)規(guī)范和需要來選擇，而不是強(qiáng)制的（比如cvs），一個不去做任何的修改的分支就是版本庫某一時(shí)刻的一個快照，相當(dāng)于為某

10、一個版本做了一個標(biāo)簽Branch和Tag都是拷貝指向原始文件的鏈接，當(dāng)你對拷貝做修改時(shí)，記錄為相對原始文件的修改，稱為延遲拷貝，效率高且?guī)缀醪徽加每臻g。Tag：版本號是個好東西，但是我們更傾向于記住像第二預(yù)覽發(fā)布版這樣的名字，而不是V01這樣的數(shù)字，標(biāo)簽是用來做這件事情的。版本控制系統(tǒng)可以讓你給某一個時(shí)刻的一組文件或者一些目錄或者整個項(xiàng)目分配一個名字。如果你給某幾個文件分配標(biāo)簽“第二發(fā)布預(yù)覽版”，以后就能使用這個標(biāo)簽簽出它們。標(biāo)簽是一種很好地跟中項(xiàng)目代碼開發(fā)過程中發(fā)生的重要事件的方式。分支合并：使用TortoiseSVN Merge命令，在“ From:(start URL and revis

11、ion of the range to merge) ”中選擇希望合并的目錄 ( 如： trunk) ，并指定希望合并的開始 revision 編號，在“ To:(end URL and revision of the range to merge) ”中選擇結(jié)束 revision 編號。然后點(diǎn)擊“ merge ”完成合并操作，剩下的工作就是編輯沖突了。當(dāng)然運(yùn)氣好的話是不需要這個過程滴。 值得注意的是，“ From: ”和“ To: ”中的 URL 通常是相同的，切記不要與創(chuàng)建分支時(shí)的含義混淆10、get lock/release lock選擇工作副本中你想要獲取鎖定的文件，然后選擇命令Tor

12、toiseSVN -> Get lock出現(xiàn)一個對話框，允許你輸入注釋，這樣別人知道你為什么鎖定這個文件。注釋是可選的，并且只用于基于Subversion 的庫。選擇需要鎖定的文件在復(fù)選框打勾，點(diǎn)擊“確定”按鈕鎖定選擇的文件：出現(xiàn)一個對話框，輸入正確的用戶名和密碼即可向版本庫提交你想鎖定文件的信息。鎖定文件成功！返回信息！”Locked by admin”表示文件已被admin 用戶鎖定；”alpay_payto.php”表示鎖定文件的名稱。點(diǎn)擊”O(jiān)K”按鈕確定鎖定文件成功。釋放鎖定（取消鎖定）選擇工作副本中你想要取消鎖定的文件，然后選擇命令TortoiseSVN -> Relea

13、se lock之后操作同get lock。當(dāng)被鎖定文件commit后，會自動解鎖，無需再去解鎖；如果commit后還需上鎖，則在commit時(shí)可選擇：“keep lock”強(qiáng)制鎖定：設(shè)置對象文件svn:needs-lock這個屬性，update后強(qiáng)制文件的屬性為只讀，只有l(wèi)ock之后，才能對文件進(jìn)行修改操作，commit-release lock之后，又自動變成只讀。具體做法：先將a.jpg文件拷貝到WC中，然后在該文件上單擊右鍵， TortoiseSVN->Add，告訴Subversion要將該文件納入版本控制， 接著在該文件上單擊右鍵并選中屬性， 在彈出的屬性對話框中選中Edit鍵，

14、在property name中如下圖。 在下拉框中選中“svn:needs-lock”， 并在下面的文本框中填入“*” （其實(shí)這里填什么都無所謂，只要文件有“svn:needs-lock”附加屬性就行）， 之后點(diǎn)Set按鈕，“svn:needs-lock”附加屬性就設(shè)置好了。 然后執(zhí)行Commit命令提交修改。 這時(shí)當(dāng)其他人執(zhí)行Update時(shí)， a.jpg就會添加到他們的WC中， 并且文件的附加屬性也會隨文件一起被得到。 可以看到a.jpg此時(shí)的圖標(biāo)就是灰色的， 文件的Windows屬性也是只讀的11、clean upSVN 本地更新時(shí)，由于一些操作中斷更新，如磁盤空間不夠，用戶取消，可能會造

15、成本地文件被鎖定的情況。一般出現(xiàn)這種情況的解決方法：(1)、可以使用SVN clean up來清除鎖定。(2)、如果不是本目錄鎖定，系統(tǒng)提示上一層目錄鎖定，需要到上一層或者根目錄中清除。(3).如果在根目錄下都無法clean的話，一般采取的方法是另外找一個目錄重新check out。但有時(shí)SVN目錄下可能有一些自己本地修改的文件，還未提交到SVN服務(wù)器，這時(shí)重新check out需要注意本地文件的備份，并且不要強(qiáng)制覆蓋服務(wù)器上其它人修改的內(nèi)容。(4)、如果覺得第種很麻煩，可以考慮這樣的方法。其實(shí)SVN加鎖會在.SVN（隱藏文件）中生成一個名字叫l(wèi)ock的文件（無后綴），查找所有的手工刪除。然后

16、再嘗試更新，系統(tǒng)可能會提示某個.base文件無法訪問。找到它，把相關(guān)的文件或其所在的目錄刪除，重新update。工作量就小多了。12、export集成測試或項(xiàng)目上線需要版本時(shí)，使用export而不用checkout，export 得到干凈的目錄與文件，不帶版本控制因素。13、Check for modifications同服務(wù)器上的項(xiàng)目版本進(jìn)行比較，并可做相應(yīng)的修改。14、Show log查看版本日志及不同版本間相互比較 15、Revision Graph版本示意圖 16、Repo-Browser查看當(dāng)前版本庫，這是TortoiseSVN查看版本庫的入口，通過這個菜單項(xiàng)，我們就可以進(jìn)入配置庫的

17、資源管理器，然后就可以對配置庫的文件夾進(jìn)行各種管理，相當(dāng)于我們打開我的電腦進(jìn)行文件管理一樣17、RenameSVN支持文件改名,點(diǎn)擊Rename,彈出文件名稱輸入框,輸入新的文件名稱,點(diǎn)擊確定,再把修改提交,即可完成文件改名。18、switch與relocate版本庫轉(zhuǎn)移，當(dāng)我們版本庫發(fā)生轉(zhuǎn)移的時(shí)候就需要用到這個功能。例如我原先的版本庫是建在U盤上的，現(xiàn)在轉(zhuǎn)移到（復(fù)制整個配置庫文件夾）開發(fā)服務(wù)器上，使用https代替文件系統(tǒng)的訪問。因此就需要將原來的工作拷貝的目標(biāo)版本庫重新定位到開發(fā)服務(wù)器上。注意：relocate與switch的區(qū)別： （1）、如果WC反應(yīng)相同的版本庫目錄，但是版本庫本身位置

18、改變了，使用relocate; （2）、如果WC需要反應(yīng)一個版本庫的新目錄，素要switch。19、switch與svn update比較：svn switch和svn update的輸出很像，switch命令只是update命令的一個超集。 當(dāng)你運(yùn)行svn update時(shí)，會告訴版本庫比較兩個目錄樹，版本庫這樣做，并且返回給客戶區(qū)別的描述，svn switch和svn update兩個命令唯一區(qū)別就是update會一直比較同一路徑。 也就是了，如果你的工作拷貝是/calc/trunk的一個鏡像，當(dāng)運(yùn)行svn update時(shí)會自動地比較你的工作拷貝的/calc/trunk與HEAD版本的/ca

19、lc/trunk。如果你使用svn switch跳轉(zhuǎn)工作拷貝到分支，則會比較你的工作拷貝的/calc/trunk與相應(yīng)分支目錄的HEAD版本。 換句話說，一個更新通過時(shí)間移動你的工作拷貝，一個轉(zhuǎn)換通過時(shí)間和空間移動工作拷貝。 因?yàn)閟vn switch是svn update的一個變種，具有相同的行為，當(dāng)新的數(shù)據(jù)到達(dá)時(shí)，任何工作拷貝的已經(jīng)完成的本地修改會被保存，這里允許你作各種聰明的把戲20、diff：（下面是針對同一個文件而言）原本錯誤地理解了 diff 的意思是比較本地的文件與服務(wù)器的相應(yīng)文件有什么不同，但實(shí)際意思并非這樣。更準(zhǔn)確地說這條語句的意思是比較一個文件中你修改過的部分與服務(wù)器的相應(yīng)文

20、件相應(yīng)部分有什么不同，對于那些沒有修改過的地方（同一文件中）不同也不會比較，當(dāng)然可以先 up 一下再 svn diff  這樣就保證了本地文件與服務(wù)器的相應(yīng)文件的所有不同的地方全都顯示出來了，當(dāng)然沖突情況除外.21、dry run合并前看看結(jié)果會是什么樣的.一個簡單的辦法就是運(yùn)行dry run先看看，并不真實(shí)的將結(jié)果寫入到工作副本中.它只是顯示在合并過程中輸出的執(zhí)行結(jié)果狀態(tài)碼.比較'高級'的預(yù)言合并,當(dāng)運(yùn)行svn diff可能會給出太多的詳細(xì)日志.22、create/apply patch (1)、使用create patch可以生成一個或者多個修改過的文件和當(dāng)前版本

21、差異的patch（支持目錄樹） 通常情況下，create patch將修改保存為.patch或.diff文件 可以將.patch或.diff文件的內(nèi)容復(fù)制出來，發(fā)給需要審查的人 .patch或.diff文件中記錄了發(fā)生這個patch的版本號以及具體修改的內(nèi)容 針對某個文件或某幾個文件的若干種修改，可以生成多個.patch或.diff文件 (2)、apply patch 可以將.patch或.diff文件應(yīng)用到對應(yīng)版本的項(xiàng)目，就像打補(bǔ)丁一樣 同一個項(xiàng)目/文件夾下，可以選擇應(yīng)用需要的patch 通常來說，應(yīng)用一個patch時(shí)文件版本和生成這個patch時(shí)文件的版本是一致的；如果不一致，也可以強(qiáng)制應(yīng)

22、用，svn會自動進(jìn)行diff（這時(shí)候需要手動合并） linux下，可以使用系統(tǒng)的patch命令來應(yīng)用patch，eg: patch -p0 <xxx.patch (3)、使用 暫時(shí)不需要提交或不允許提交的修改，可以選擇create patch來保存修改的內(nèi)容 選擇create patch來保存修改的內(nèi)容并且提交patch，通過審查后，(在服務(wù)器端)應(yīng)用patch 當(dāng)一個功能有多種解決方案時(shí)，可以生成多個patch，（提交后）分別經(jīng)過測試，再決定應(yīng)用哪個patch 多個功能分別需要改同一個文件的不同地方（即沒有同一行），可以做成多個patch，應(yīng)用patch的順序沒有要求（在linux下應(yīng)

23、用也一樣成功，只是會生成多個.orig文件）多個連續(xù)性的功能，他們修改的文件都與一個base作patch，例：p1在v1的基礎(chǔ)上開發(fā)v2，生成v2和v1之間的patch1；p2在v2的基礎(chǔ)上開發(fā)v3，生成v3和v1之間的patch2，這樣只要應(yīng)用patch2也就應(yīng)用了patch1。 (4)、帶來的問題一個較早的patch，在經(jīng)過多輪提交后，如果想再要應(yīng)用，需要嚴(yán)格的diff 如果兩個patch分別改了同一行代碼，應(yīng)用第一個patch后要再應(yīng)用第二個patch時(shí)，仍然需要diff。如果在linux下，會產(chǎn)生沖突，生成.orig和.rej兩個文件（此時(shí)仍然需要手動進(jìn)行比較合并）第3部分提到的連續(xù)性

24、，要準(zhǔn)確的預(yù)見到，比較困難 第3部分提到的多個連續(xù)的功能，后做的功能的某個文件更新了先做的功能的內(nèi)容，但先做的功能可能還涉及到其他文件，容易造成漏更新文件的情況 23、subversion的版本控制模型 當(dāng)你用subversion進(jìn)行版本控制時(shí)， Subversion會記錄你對Repository進(jìn)行的每一次修改(包括添加，修改，刪除等等)， 每修改一次Repository都會產(chǎn)生一個新的Revision(修訂版本號)， 不同的Revision代表了不同時(shí)刻Repository的狀態(tài)， 因此我們可以用這個Revision回朔任意時(shí)刻Repository的狀態(tài)， 就像時(shí)間機(jī)器一樣，也就是說某一R

25、evision 就是Repository在某一時(shí)刻的一個“快照”。 注意：Revision不是針對某一個文件或者目錄， 而是針對整個Repository而言的。 每修改一次Repository，Revision 都會增加1。 Subversion的版本控制模型是一種叫做Copy-Modify-Merge (拷貝-修改-合并)的模型。 考慮這種情況： 張三和李四是公司同一個部門的同事， 他們共同維護(hù)一個文本文件a.txt， 并且對該文件進(jìn)行版本控制， 因此他們把這個文件放到一個Repository上共同維護(hù)該文件。 周一上午9點(diǎn)，張三和李四同時(shí)想對a.txt文件進(jìn)行修改， 于是他們同時(shí)從Repo

26、sitory上取得該文件的最新版本(Revision 10)， 然后進(jìn)行修改。過了三分鐘，張三首先完成了修改， 他在該文件的第五行修改了一個單詞的拼寫(將Typo改為Type)， 于是張三對修改后的文件執(zhí)行Commit命令， 將修改提交到服務(wù)器端的Repository中。 這時(shí)Repository的Revision變?yōu)?1。 六分鐘過后，李四也完成了他的修改， 他修改了該文件第十行上的一個單詞拼寫(將He改為She)， 于是他也對修改后的文件執(zhí)行Commit命令， 這時(shí)Subversion 在提交修改時(shí)會發(fā)現(xiàn)， 李四修改的文件是Revision10的a.txt文件， 而不是最新的Revisio

27、n 11的a.txt文件。 于是，Subversion 提示李四在提交修改前， 應(yīng)該先將Working Copy更新到最新版本， 李四執(zhí)行Update命令將Working Copy更新到Revision 11， 這時(shí)Subversion會提示已經(jīng)完成合并， 李四的a.txt文件的第五行的“Typo”已經(jīng)變?yōu)榱恕癟ype”， 第十行還是“She”，就是說Subversion已經(jīng)將張三的修改“合并”到李四的a.txt文件中了。 之后，李四再執(zhí)行Commit命令，就能將他對第十行的修改(將He改為She) 提交到服務(wù)器端的Repository中了(生成Revision 12)。 但是這種合并在某些情

28、況下會變得復(fù)雜一些， 比如：李四對a.txt文件的修改并不是第十行， 而是與張三同樣修改第五行的單詞， 李四將“Typo”改為“Typr”，并且提交修改， 這時(shí)Subversion會提示李四在提交修改前， 應(yīng)該先將Working Copy更新到最新版本， 李四執(zhí)行Update命令將Working Copy更新到Revision 11， 這時(shí)Subversion將Revision11的a.txt文件與 李四修改的a.txt文件進(jìn)行合并時(shí)發(fā)現(xiàn)李四修改的同樣是第五行， 于是Subversion就無法判斷是李四的修改(“Tpyr”) 正確還是張三的修改(“Type”)正確， 因?yàn)樗麄兌际窃赗evisi

29、on10的a.txt基礎(chǔ)上作的修改。 這種情況叫做Conflict(沖突)， a.txt文件的圖標(biāo)會變成一個黃色三角。 這時(shí)，只能依靠李四自己去判斷到底第三行應(yīng)該修改為“Typr”還是“Type”。 當(dāng)李四確定修改之后，在a.txt文件上單擊右鍵，TortoiseSVN->Resolved 告訴Subversion已經(jīng)解決了Conflict。 這時(shí)再執(zhí)行Commit命令就能提交修改(生成Revision 12)。 Subversion 這種控制方式保證了你對文件所作的修改都是基于文件的最新版本。24、“.svn”目錄 在客戶端Working Copy的每一層目錄中都會有一個“.svn”目

30、錄， 該目錄是Subversion進(jìn)行管理用的目錄。 不要手動修改其中的文件。 該目錄存儲了Working Copy的一個副本 實(shí)際存儲副本的地方是F:project1.svntext-base目錄 比如：F:Project1是一個Working Copy， 該目錄下有兩個文件a.txt和b.txt還有一個子目錄ccc， 子目錄ccc中還有一個d.txt文件。 “.svn”目錄中存儲的是你最近一次執(zhí)行完Update或者Commit命令之后當(dāng)前目錄中文件的副本， 比如：F:project1.svntext-base中存儲的a.txt和b.txt 是最近一次執(zhí)行完Update或者Commit命令之

31、后F:project1下的a.txt和b.txt的拷貝。 也就是說你所作的修改都是基于“.svn”目錄存儲的那些文件。 這種機(jī)制可以讓我們在不連接網(wǎng)絡(luò)的情況下， 將Working Copy中的文件恢復(fù)到修改之前的狀態(tài)。 Subversion的Revert命令就是利用了這種機(jī)制來實(shí)現(xiàn)的。 比如你修改了F:project1a.txt文件， 這時(shí)你又改變了主意想放棄對該文件的修改， 你可以單擊右鍵，TortoiseSVN->Revert， 修改過的F:project1a.txt文件 就會被F:project1.svntext-base中a.txt文件的副本所替代， 使得a.txt恢復(fù)到修改前的

32、狀態(tài)。 Working Copy中每一個子目錄下都會有一個“.svn”目錄， 并不是只有最上層目錄才有“.svn”目錄。 所以，F(xiàn):project1ccc下也有一個“.svn”目錄， 該目錄存儲的是F:project1cccd.txt的副本 (d.txt的副本位于F:project1ccc.svntext-base)。 也就是說每個“.svn”目錄只存儲同級目錄中的“文件”副本， 而不存儲“目錄”副本?！?svn”目錄存有許多重要的內(nèi)容， 所以前面說在刪除文件或目錄時(shí)， 必須用TortoiseSVN->Delete， 而不能用windows自帶的”刪除”或者“Delete”鍵來刪除文件或

33、目錄，尤其是對于目錄的刪除。 25、混合版本 Subversion的Working Copy被設(shè)計(jì)成一種能夠包含不同版本的文件共存的形式。 比如F:Project1是一個Working Copy， 該目錄下有兩個文件a.txt和b.txt。 執(zhí)行Update命令，將Working Copy更新到最新版本（Revision 24）。 這時(shí)，a.txt和b.txt的Revision都是24 (其實(shí)對于單個文件來說并不存在Revision， Revision是對于整個Repository而言的， 這里所指的是Repository的Revision24所存儲的a.txt和b.txt， 但為了方便而采用

34、這種描述方式，請注意，下同）。 之后，你的同事修改了a.txt，并且提交了修改， 這時(shí)Repository的Revision就變成25了。 注意，這時(shí)你沒有再次執(zhí)行Update， 因此你的Working Copy的Revision還是24。 這時(shí)你修改了b.txt文件，并提交修改。 因?yàn)镽evision25并沒有對b.txt文件進(jìn)行修改， 因此你對b.txt文件的修改是基于b.txt文件最新的版本， 所以不會出現(xiàn)Conflict。 當(dāng)你提交b.txt的修改后，產(chǎn)生Revision26。 這時(shí)你會發(fā)現(xiàn)你的Working Copy中的a.txt文件并不是Revision25中的a.txt文件， 它

35、還是Revision24的a.txt文件，而你的b.txt文件是Revision26的b.txt文件。 也就是說當(dāng)你Commit時(shí)，你的Working Copy中只有你提交的那些文件是最新版本， 而其他沒有修改的文件并不會更新為最新版本。 這樣就造成了你的Working Copy由不同的Revision文件所組成 (Revision24的a.txt文件和Revision26的b.txt文件)。 前面說過在提交修改前必須保證你是在文件的最新版本基礎(chǔ)上修改， 如果在這種混合版本的情況下， 怎樣才能知道當(dāng)前Working Copy中的文件是否為最新版本？ 在前面所說的“.svn”目錄中有一個文件名為

36、“entries”的文件， 該文件記錄了當(dāng)前Working Copy中的每一個文件的Revision， 因此當(dāng)你Commit時(shí)，Subversion會從該文件中取得你提交文件的Revision， 再與Repository的最新Revision一比較就可以知道你修改的文件是否基于該文件的最新版本。 26、文件的附加屬性 在Subversion中，每個文件可以擁有一種叫做附加屬性的東西。 附加屬性描述了該文件所擁有的一些特性。 Subversion已經(jīng)預(yù)定義了一些附加屬性（這里只是指Subversion已經(jīng)定義了一些附加屬性的“名稱”， 并不是指已經(jīng)將這些屬性附加在文件上了， 比如默認(rèn)情況下文本文件一開始不含任何屬性， 直到人為的對該文件添加附加屬性）， 并且你可以對文件添加自定義的屬性。 Subversion對待附加屬性就像對待文件內(nèi)容一樣， 當(dāng)修改了一個文件的附加屬性（添加，改變，刪除附加屬性）， 即使沒有對文件的內(nèi)容進(jìn)行修改， 同樣可以Commit該文件，就像更改了文件內(nèi)容那樣， Repository也會生成新的Revision， 所以從