svn使用手冊.doc

Tortoise SVN 快速操作手冊1.庫的存儲結(jié)構(gòu)版本庫文件結(jié)構(gòu)如圖所示：Code文件夾為源碼文件夾，doc為文檔目錄文件夾，1.1 branch：分枝文件夾當(dāng)多個人合作，可能有這樣的情況出現(xiàn)：John突然有個想法，跟原先的設(shè)計不太一致，可能是功能的添加或者日志格式的改進(jìn)等等，總而言之，這個想法可能需要花一段時間來完成，而這個過程中，John的一些操作可能會影響Sally的工作，John從現(xiàn)有的狀態(tài)單獨出一個project的話，又不能及時得到Sally對已有代碼做的修正，而且獨立出來的話，John的嘗試成功時，跟原來的合并也存在困難。這時最好的實踐方法是使用branch。John建立一個自己的branch，然后在里面實驗，必要的時候從trunk里取得更新，或者將自己的階段成果匯集到trunk中。1.2 tag: 標(biāo)簽在經(jīng)過了一段時間的開發(fā)后，項目到達(dá)了一個里程碑階段，你可能想記錄這一階段的代碼的狀態(tài)，那么你就需要給代碼打上標(biāo)簽。1.3 trunk：主干主干，一般來說就是開發(fā)的主要呆的地方，比較穩(wěn)定的發(fā)布版本一般放這個地方。文檔等文件放入doc文件夾中。branch文件夾開發(fā)人員可讀可寫，測試人員可讀。新功能開發(fā)或者bug修復(fù)完畢，經(jīng)過單元測試無誤后，提交申請，由項目經(jīng)理合并進(jìn)主干線路。tag文件夾，由項目經(jīng)理在固定時間間隔備份trunk文件夾，項目經(jīng)理可讀寫，開發(fā)人員可讀，測試人員可讀。當(dāng)開發(fā)人員通過分支或者打補(bǔ)丁的形式修復(fù)bug后，由項目經(jīng)理合并進(jìn)主干線路。2.基本操作2.1 搭建一個工作環(huán)境新建一個空白文件夾檢出版本數(shù)據(jù)庫數(shù)據(jù)。 選擇svn檢出輸入版本庫主干目錄的url地址，00/svn/project/code/trunk，導(dǎo)出版本庫文件。并設(shè)置檢出目錄地址。D:softsample點確定繼續(xù)點擊“總是接受”。輸入用戶名，密碼。版本庫檢出成功，如上圖所示，綠色勾表示狀態(tài)正常，其他圖列示意請參考附錄A：強(qiáng)制寫log為保證版本庫有良好的可讀性，須設(shè)置在每次更新或者修改文件版本時，必須設(shè)置其屬性為強(qiáng)制寫log。對工作副本點右鍵，選擇屬性。選擇subversion選項，設(shè)置其屬性選擇new，新建屬性在property name 的下拉菜單中選擇為tsvn:logminsize屬性，并設(shè)置property value值為1，即log最小字節(jié)數(shù)應(yīng)該為1.并勾選上apply property recursively 設(shè)置其屬性為遞歸。2.2 上傳，更新版本庫對當(dāng)前工作目錄點右鍵，出現(xiàn)如下菜單。Svn update 是把服務(wù)器上版本庫更新到本地Svn commit 是把本地文件更新到服務(wù)器。2.3 版本日志選擇 TortoiseSVN-show log，可以查看歷史的版本。對針對歷史版本做比較和更改對某一版本點右鍵可查看詳細(xì)操作菜單Compare with working copy 將你的工作版本與選中的版本進(jìn)行比較。默認(rèn)的比較工具是與 TortoiseSNV 一同發(fā)布的 TortoiseMerge，如果日志對話框是針對文件夾的，那么就會出現(xiàn)一個被修改的文件的列表，你可以單獨地查看每個文件所做的修改。Show changes as unified diff 將選中的版本作為單一差異文件(GNU補(bǔ)丁格式)查看。相對于可視化的文件比較器，它更難閱讀，但它將所有的變化顯示在一個格式更為緊湊的文件中。Compare with previous revision 比較選中的版本和以前版本。它與比較工作副本類似。對于文件夾，這個選項首先會顯示已修改的文件對話框讓你選擇要比較的文件。Compare and blame with previous revision顯示已修改的文件對話框，讓你選擇文件。追溯選中的版本和舊版本，用可視化差異工具比較結(jié)果(僅對于文件夾)。Browse repository 打開版本庫瀏覽器，基于選中的版本，在版本庫中檢查選中的文件或目錄。Create branch/tag from revision從選中的版本建立一個分支/標(biāo)記。這個選項很有用。比如: 如果你忘記建立標(biāo)記，并且提交了某些你不想使其進(jìn)入發(fā)行版的修改。Update item to revision 將你的工作副本更新到選中的版本。如果你想要你的工作副本折返到過去的某個時間，或者在版本庫中有一系列提交而你想每次只更新工作副本一小步，那這個功能就很好用。你最好是更新工作副本的整個目錄而不是單一某個文件，因為如果只更新某個文件，否則你的工作副本就可能不一致。如果你想要永久撤銷先前的更改，使用 復(fù)原到此版本。Update item to revision 恢復(fù)到某個以前的版本。如果你做了多處修改，然后決定要返回到版本 N，你就可以使用這個命令?；謴?fù)的修改位于你的工作副本，在你提交之前，并不會影響版本庫。注意，這將會丟棄從那個版本以來的所有修改，使用選中的版本來替換文件/文件夾。如果你的工作副本處于未修改的狀態(tài)，在執(zhí)行此操作后，工作副本將會顯示為已修改。如果你已經(jīng)進(jìn)行了本地修改，這個命令將會把撤銷的改變合并至你的工作副本中。內(nèi)部的動作是 Subversion 對選中版本之后的修改內(nèi)容執(zhí)行了反向合并，撤銷這些先前提交產(chǎn)生的影響。如果在執(zhí)行這個動作后你察覺到你需要撤銷這次撤銷并且讓工作副本返回到先前沒有修改的狀態(tài)，你應(yīng)該在 Windows 資源管理器中使用 TortoiseSVN SVN 還原， 這個命令將會丟棄本次撤銷動作帶來的修改。如果你只是想看看某個文件或者文件夾在先前的版本是什么樣子，使用 更新至版本 或 保存版本為. 功能替代此操作。Revert changes from this revision 還原選中版本所做的修改。還原的內(nèi)容只在你的工作副本中，所以此操作完全不會影響版本庫！要注意的是，這個操作僅僅還原該版本中的修改。不是將整個文件替換成選中的那個版本。它對于已經(jīng)做過其它無關(guān)修改的還原早期修改非常有用。內(nèi)部的動作是 Subversion 對這個版本的修改內(nèi)容執(zhí)行了反向合并，撤銷先前提交產(chǎn)生的影響。你可以使用上文復(fù)原到此版本中描述的撤銷這次撤銷。Revert changes from this revision. 合并選中的版本到不同的工作副本?？梢酝ㄟ^文件夾選擇對話框來確定合并到哪一個工作副本中，但是此操作沒有沖突對話框，也沒有嘗試測試合并的機(jī)會。合并到未修改的工作副本是一個好主意，這樣當(dāng)合并不成功時你可以還原工作副本。當(dāng)你想要將某個分支上選中的版本合并至其他分支時，這個功能很有用。checkout. 檢出你選擇的目錄的選中版本，創(chuàng)建一個全新副本。它彈出對話框，讓你確認(rèn)URL和版本，并且選擇保存的位置。Export. 導(dǎo)出選擇的文件/目錄的選中版本。它彈出對話框，讓你確認(rèn)URL和版本，選擇導(dǎo)出位置。Edit author / log message 編輯之前提交時的日志信息或是作者。Show revision properties 查看和編輯任何版本屬性，不僅僅是日志信息和作者。Show revision properties 將選中版本的詳細(xì)日志信息復(fù)制到剪貼板。它會復(fù)制版本號，作者，日期，日志信息，以及每個版本的改變項目列表。Search log messages. 在日志信息中搜索你輸入的的文字。這個操作搜索日志信息，也搜索由Subversion建立的提交行為總結(jié)(最底部的面板中的內(nèi)容)。搜索大小寫無關(guān)。2.4版本庫瀏覽器瀏覽當(dāng)前版本庫內(nèi)容。2.5 檢查修改可檢查當(dāng)前目錄做過修改的文件2.6 版本分支圖版本分支圖能夠顯示分支/標(biāo)簽從什么地方開始創(chuàng)建，以及什么時候刪除。2.7 鎖定解鎖文件Get lock功能可給某一文件加鎖，比如開發(fā)人員a從版本庫里面下載aaa文件進(jìn)行更改，但他不想別人在他之后修改此文件，于是他可以給此文件加鎖，如開發(fā)人員b需要修改aaa文件，必須先由開發(fā)人員a對aaa文件進(jìn)行解鎖后，才能進(jìn)行修改。3. 創(chuàng)建以及應(yīng)用補(bǔ)丁對開源工程(比如本工程)來說，每個人對倉庫都有讀訪問權(quán)，并且任何人都可以對該工程做出修改。那么如何控制這些修改呢？如果任何人都可以提交自己的修改，那么這個工程可能永遠(yuǎn)都會處于不穩(wěn)定狀態(tài)，而且很有可能永遠(yuǎn)的癱瘓下去。在這種情況下，修改需要以補(bǔ)丁文件的形式先遞交到有寫訪問權(quán)限的開發(fā)組。開發(fā)組可以先對該補(bǔ)丁文件進(jìn)行審查，然后決定將其提交到倉庫里或者是退還給修改者。創(chuàng)建一個補(bǔ)丁文件修改欲修改的文件內(nèi)容后，在當(dāng)前目錄選擇TortoiseSVN Create patch.勾選修改的文件，確定，會生成一個*.patch的文件，可以通過郵件或者ftp方式將此文件發(fā)送給有權(quán)限寫目錄的開發(fā)人員。應(yīng)用一個補(bǔ)丁文件開發(fā)人員收到*.patch 文件后，進(jìn)入本地工作副本目錄，點擊TortoiseSVN apply patch. 系統(tǒng)會彈出一個打開文件的對話框，讓你選擇要應(yīng)用的補(bǔ)丁文件。選擇接受到的patch文件，確定，系統(tǒng)會彈出一個小窗口列出所有被更改了的文件。依次雙擊每一個文件，檢查所做的改變，然后保存合并后的文件。遠(yuǎn)程開發(fā)者的補(bǔ)丁現(xiàn)在已經(jīng)應(yīng)用到了你的工作副本上，你需要提交它以使每一個人都可以從代碼庫訪問到這些修改。4.分支以及合并4.1 分支a.新建一個空白文件夾。b.點擊鼠標(biāo)右鍵checkout，把svn服務(wù)器上的庫文件下載到本地，注意，不用下載全部的文件，只下載trunk下主干文件就夠了c.下載后對文件夾點右鍵，選擇branch/tag選項。建立一個分支。設(shè)置好分支文件夾的路徑，創(chuàng)建一個屬于自己的分支。每個分支存在壽命應(yīng)該盡量的短，否則在跟主干合并時會造成很多沖突。注意：勾選上switch working copy to new branch./tag，把分支設(shè)為當(dāng)前工作目錄。這樣當(dāng)對程序有改動時，就直接commit到分支目錄了。4.2 合并4.2.1 從開發(fā)主線合併至分支線路 由于要開發(fā)一個新功能，從主干新建一個分支后，主干又有其他的變化，需要保持分支的最新狀態(tài)，所以需要從主干把新內(nèi)容合并過去。操作步驟如下：A：在分支目錄下點擊鼠標(biāo)右鍵，選擇merge選項。B：在彈出框中選擇“Merge a range of reversion”選項。C：在URL TO MERGE FROM 選擇主干文件的路徑00/svn/project/code/trunkREVISION RANGE TO MERGE 這里可選擇版本號，如不選擇，則默認(rèn)最新版本。D：下一步可先點擊test merge查看下測試合并結(jié)果。如果修改與update得到的代碼不沖突，則自動合并。如果沖突（比如對同一行代碼進(jìn)行了修改），則出現(xiàn)”O(jiān)ne or more files are in a conflicted state.“紅色警告，并產(chǎn)生幾個文件記錄沖突。如下圖所示。 此時點擊edit conflict按鈕，解決沖突。出現(xiàn)界面，分為”Theirs”、”Mine”和”Merged”3部分，表示”別人修改的內(nèi)容”、 ”我修改的內(nèi)容”和”合并后的結(jié)果”3部分。我們是要將”別人修改的內(nèi)容”和”我修改的內(nèi)容”有取舍地合并起來，形成”合并后的結(jié)果”。 合并一般分為4種情況： 保留”我的修改”,舍棄”別人的修改”。鼠標(biāo)右鍵點擊Mine框的相應(yīng)行，點擊”Use this text block”。 舍棄”我的修改”,保留”別人的修改”。鼠標(biāo)右鍵點擊Theirs框的相應(yīng)行，點擊”Use this text block”。保存，退出并點擊resolved按鈕，為文件解決沖突。解決之后如圖所示即分支文件已更新。4.2.2分支線路合併回 開發(fā)主線 最後我們的 tes1分支已經(jīng)將新功能開發(fā)完成且測試無誤，所以要將 分支線路 ( /code/branches/tes1 ) 的最終版本合併回 開發(fā)主線 ( /code/trunk )，這時的步驟如下：A：切換到trunk主干目錄文件夾下面。B：選擇合并C：選擇Reintergrate a branch 選項。D：設(shè)置url為欲合并的分支目錄E：合并成功，若出現(xiàn)沖突請按照 4.2.1 D步驟解決。F：手工檢查更新過的單元文件，核對無誤后上傳到版本庫。4.2.3 分支線路合并回主線（通用模式）這是復(fù)興合并的通用情況。你要 Subversion 做如下事情: “計算從主干的最新版本到分支的最新版本所需要的修改，并將這些修改應(yīng)用到(主干的)工作副本?！弊罱K結(jié)果就是主干看起來與分支一模一樣。選擇merge two different trees選項From下面這里填寫主干的url地址。To下面填寫欲合并的分支文件地址合并成功，請檢查無誤后提交版本庫附錄A.圖標(biāo)狀態(tài)示例一個新檢出的工作副本使用綠色的對勾做重載。表示 Subversion 狀態(tài)正常.在你開始編輯一個文件后，狀態(tài)就變成了已修改，而圖標(biāo)重載變成了紅色感嘆號。通過這種方式，你可以很容易地看出哪些文件從你上次更新工作副本后被修改過，需要被提交。如果在更新的過程中出現(xiàn)了沖突，圖標(biāo)會變成黃色感嘆號。如果你給一個文件設(shè)置了svn:needs-lock屬性，Subversion 會讓此文件只讀，直到你獲得文件鎖。具有這個重載圖標(biāo)的文件來表示你必須在編輯之前先得到鎖。如果你擁有了一個文件的鎖，并且 Subversion 狀態(tài)是正常，這個重載圖標(biāo)就提醒你如果不使用該文件的話應(yīng)該釋放鎖，允許別人提交對該文件的修改。這個圖標(biāo)表示當(dāng)前文件夾下的某些文件或文件夾已經(jīng)被調(diào)度從版本控制中刪除，或是該文件夾下某個受版本控制的文件丟失了。加號告訴你有一個文件或目錄已經(jīng)被調(diào)度加入版本控制。橫條告訴你有一個文件或目錄被版本控制系統(tǒng)所忽略。這個圖標(biāo)重載是可選的。這個圖標(biāo)說明文件和目錄未被版本控制，但是也沒有被忽略。這個圖標(biāo)重載是可選的。附錄B、常見問題1.出現(xiàn)樹沖突的幾種情況以及解決方案。當(dāng)一名開發(fā)人員移動、重命名、刪除一個文件或文件夾，而另一名開發(fā)人員也對它們進(jìn)行了移動、重命名、刪除或者僅僅是修改時就會發(fā)生樹沖突。B1.本地刪除，當(dāng)更新時有更改進(jìn)入1. 開發(fā)人員 A 修改 Foo.c 并將其提交至版本庫中2. 開發(fā)人員 B 同時在他的工作副本中將文件 Foo.c 改名為 Bar.c，或者僅僅是刪除了 Foo.c 或它的父文件夾。更新開發(fā)人員 B 的工作副本會導(dǎo)致樹沖突: 在工作副本中，F(xiàn)oo.c 被刪除了，但是被標(biāo)記為樹沖突。 如果沖突是由于更改文件名引起的而不是刪除文件引起的，那么 Bar.c 被標(biāo)記為添加，但是其中卻不包括開發(fā)人員 A 修改的內(nèi)容。開發(fā)人員 B 現(xiàn)在必須做出選擇是否保留開發(fā)人員 A 的更改。在更改文件名的案例中，他可以將 Foo.c 的更改合并到改名后的文件 Bar.c 中去。對于刪除文件或文件夾的案例中，他可以選擇保留包含開發(fā)人員 A 更改內(nèi)容的項目并放棄刪除操作?；蚴裁匆膊蛔龆苯訉_突標(biāo)記為已解決，那樣他實際上丟棄了開發(fā)人員 A 的更改。如果 TortoiseSVN 能夠找到被改名為 Bar.c 的原始文件，沖突編輯對話框?qū)⒖梢院喜⒏?。這取決于在什么地方調(diào)用更新操作，它也許不能找到原始文件。B2.本地更改，當(dāng)更新時有刪除進(jìn)入1. 開發(fā)人員 A 將文件 Foo.c 改名為 Bar.c 并將其提交至版本庫中。2. 開發(fā)人員 B 在他的工作副本中修改文件 Foo.c?；蛘咴谝粋€文件夾改名的案例中.1. 開發(fā)人員 A 將父文件夾 FooFolder 改名為 BarFolder 并將其提交至版本庫中。2. 開發(fā)人員 B 在他的工作副本中修改文件 Foo.c。更新開發(fā)人員 B 的工作副本會導(dǎo)致樹沖突。對于一個簡單的文件沖突: Bar.c 被當(dāng)作一個正常文件添加到工作副本中。 Foo.c 被標(biāo)記為添加(包括其歷史記錄)并且產(chǎn)生樹沖突。對于一個文件夾沖突: BarFolder 被當(dāng)作一個正常文件夾添加到工作副本中。 FooFolder 被標(biāo)記為添加(包括其歷史記錄)并且產(chǎn)生樹沖突。Foo.c 被標(biāo)記為已修改。開發(fā)人員 B 現(xiàn)在需要做出決定是否接受開發(fā)人員 A 作出的結(jié)構(gòu)改變并且合并她的更改到新結(jié)構(gòu)下適當(dāng)?shù)奈募?，或者直接放棄開發(fā)人員 A 的更改并保留本地文件。要合并她的本機(jī)更改到新布局中，開發(fā)人員 B 必須先找出沖突的文件 Foo.c 經(jīng)過改名/移動后在版本庫中的新文件名是什么?？梢允褂萌罩緦υ?刪除按鈕進(jìn)行清理并將沖突標(biāo)記為已解決。如果開發(fā)人員 B 認(rèn)為 A 的更改是錯誤的，那么在沖突編輯對話框中她必須選擇保留按鈕。這樣就會標(biāo)記沖突的文件/文件夾為已解決，但是需要手工刪除開發(fā)人員 A 的更改。又是通過日志對話框幫助追蹤哪些文件移動了。B3.本地刪除，當(dāng)更新時有刪除進(jìn)入1. 開發(fā)人員 A 將文件 Foo.c 改名為 Bar.c 并將其提交至版本庫中。2. 開發(fā)人員 B 將文件 Foo.c 改名為 Bix.c更新開發(fā)人員 B 的工作副本會導(dǎo)致樹沖突: Bix.c 被標(biāo)記為添加(包括其歷史記錄)。 Bar.c 被添加到工作副本中，其狀態(tài)為正常。 Foo.c 被標(biāo)記為刪除并且產(chǎn)生一個樹沖突。要解決這個沖突，開發(fā)人員 B 必須找出沖突的文件 Foo.c 經(jīng)過改名/移動后在版本庫中的新文件名是什么?？梢允褂萌罩緦υ捒騺硗瓿蛇@個任務(wù)。然后，開發(fā)人員 B 需要決定 Foo.c 的新文件名中的哪一個需要保留 - 開發(fā)人員 A 改的那個還是他自己改的那個。在開發(fā)人員 B 手工解決沖突后，使用沖突編輯對話框中的按鈕將樹沖突標(biāo)記為已解決。B4.本地缺少，當(dāng)合并時有更改進(jìn)入1. 開發(fā)人員 A 在主干上工作，修改 Foo.c 并將其提交至版本庫中2. 開發(fā)人員 B 在分支上工作，將 Foo.c 改名為 Bar.c 并將其提交至版本庫中合并開發(fā)人員 A 的主干更改到開發(fā)人員 B 的分支工作副本會導(dǎo)致樹沖突: Bar.c 已經(jīng)存在于工作副本中，其狀態(tài)為正常。 Foo.c 被標(biāo)記為缺少并產(chǎn)生樹沖突。要解決這個沖突，開發(fā)人員 B 要在沖突編輯對話框中標(biāo)記文件為已解決，這樣就會將其從沖突列表中刪除。她接下來需要決定是否將缺少的文件 Foo.c 從版本庫中復(fù)制到工作副本中，是否將開發(fā)人員 A 的對 Foo.c 的更改和合并到改名后的 Bar.c 或者是否通過標(biāo)記沖突為已解決來忽略更改什么事也不做。注意，如果你將缺少的文件從版本庫中復(fù)制到工作副本中然后再標(biāo)記為已解決，你復(fù)制下來的文件將被再次刪除。你必須先解決沖突。B5.本地更改，當(dāng)合并時有刪除進(jìn)入1. 開發(fā)人員 A 在主干上工作，將 Foo.c 改名為 Bar.c 并將其提交至版本庫中2. 開發(fā)人員 B 在分支上工作，修改 Foo.c 并將其提交至版本庫中當(dāng)文件夾改名時有類似的案例，但是在 Subversion 1.6 中還未被識別.1. 開發(fā)人員 A 在主干上工作，將父文件夾 FooFolder 改名為 BarFolder 并將其提交至版本庫中。2. 開發(fā)人員 B 在分支上工作，在她的工作副本中修改 Foo.c 。合并開發(fā)人員 A 的主干更改到開發(fā)人員 B 的分