基本的工作周期 · SVN版本管理詳解

### 基本的工作周期 Subversion有許多特性、選項和華而不實的高級功能，但日常的工作中你只使用其中的一小部分，有一些只在特殊情況才會使用，在這一節里，我們會介紹許多你在日常工作中常見的命令。典型的工作周期是這樣的： - 更新你的工作拷貝 - **svn update** - 做出修改 - **svn add** - **svn delete** - **svn copy** - **svn move** - 檢驗修改 - **svn status** - **svn diff** - **svn revert** - 合并別人的修改到工作拷貝 - **svn update** - **svn resolved** - 提交你的修改 - **svn commit** ### 更新你的工作拷貝當你在一個團隊的項目里工作時，你希望更新你的工作拷貝得到所有其他人這段時間作出的修改，使用**svn update**讓你的工作拷貝與最新的版本同步。 ~~~ $ svn update U foo.c U bar.c Updated to revision 2. ~~~ 這種情況下，其他人在你上次更新之后提交了對`foo.c`和`bar.c`的修改，因此Subversion更新你的工作拷貝來引入這些更改。讓我們認真檢查**svn update**的輸出，當服務器發送修改到你的工作拷貝，一個字母顯示在每一個項目之前，來讓你知道Subversion對你的工作拷貝做了什么操作： `U foo` 文件`foo`更新了（從服務器收到修改）。 `A foo` 文件或目錄`foo`被添加到工作拷貝。 `D foo` 文件或目錄`foo`在工作拷貝被刪除了。 `R foo` 文件或目錄`foo`在工作拷貝已經被替換了，這是說，`foo`被刪除，而一個新的同樣名字的項目添加進來，它們具有同樣的名字，但是版本庫會把它們看作具備不同歷史的不同對象。 `G foo` 文件`foo`接收到版本庫的更改，你的本地版本也已經修改，但改變沒有互相影響，Subversion成功的將版本庫和本地文件合并，沒有發生任何問題。 `C foo` 文件`foo`的修改與服務器沖突，服務器的修改與你的修改交迭在一起，不要恐慌，這種沖突需要人（你）來解決，我們在后面的章節討論這種情況。 ### 修改你的工作拷貝現在你可以開始工作并且修改你的工作拷貝了，你很容易決定作出一個修改（或者是一組），像寫一個新的特性，修正一個錯誤等等。這時可以使用的Subversion命令包括**svn add**、 **svn delete**、**svn copy**和**svn move**。如果你只是修改版本庫中已經存在的文件，在你提交之前，不必使用上面的任何一個命令。你可以對工作備份作的修改包括：文件修改這是最簡單的一種修改，你不必告訴Subversion你想修改哪一個文件，只需要去修改，然后Subversion會自動地探測到哪些文件已經更改了。目錄樹修改你可以“標記”目錄或者文件為預定要刪除、增加、復制或者移動，也許這些改動在你的工作拷貝馬上發生，而版本庫只在你提交的時候才發生改變。修改文件，可以使用文本編輯器、字處理軟件、圖形程序或任何你常用的工具，Subverion處理二進制文件像同文本文件一樣―效率也一樣。這些是常用的可以修改目錄樹結構的子命令（我們會在后面包括**svn import**和**svn mkdir**）。 ### 警告你可以使用任何你喜歡的工具編輯文件，但你不可以在修改目錄結構時不通知Subversion，需要使用**svn copy**、**svn delete**和**svn move**命令修改工作拷貝的結構，使用**svn add**增加版本控制的新文件或目錄。 **svn add foo** 預定將文件、目錄或者符號鏈`foo`添加到版本庫，當你下次提交后，`foo`會成為其父目錄的一個子對象。注意，如果`foo`是目錄，所有foo中的內容也會預定添加進去，如果你只想添加`foo`本身，使用`--non-recursive`（`-N`）參數。 **svn delete foo** 預定將文件、目錄或者符號鏈`foo`從版本庫中刪除掉，如果foo是文件，它馬上從工作拷貝中刪除，如果是目錄，不會被刪除，但是Subversion準備好刪除了，當你提交你的修改，`foo`就會在你的工作拷貝和版本庫中被刪除。 **svn copy foo bar** 建立一個新的項目`bar`作為`foo`的復制品，當在下次提交時會將`bar`添加到版本庫，這種拷貝歷史會記錄下來（按照來自`foo`的方式記錄），**svn copy**并不建立中介目錄。 **svn move foo bar** 這個命令與與運行**svn copy foo bar; svn delete foo**完全相同，`bar`作為`foo`的拷貝準備添加，`foo`已經預定要被刪除，**svn move**不建立中介的目錄。 **不通過工作拷貝修改版本庫** 本章的前面曾經說過，為了使版本庫反映你的改動，你應該提交所有改動。這并不完全正確―有一些方式*是*可以直接操作版本庫的，當然只有子命令直接操作URL而不是本地拷貝路徑時才可以實現，通常**svn mkdir**、**svn copy**、**svn move**、和 **svn delete**可以使用URL工作。指定URL的操作方式有一些區別，因為在使用工作拷貝的運作方式時，工作拷貝成為一個“集結地”，可以在提交之前整理組織所要做的修改，直接對URL操作就沒有這種奢侈，所以當你直接操作URL的時候，所有以上的動作代表一個立即的提交。 ### 檢查你的修改當你完成修改，你需要提交他們到版本庫，但是在此之前，檢查一下做過什么修改是個好主意，通過提交前的檢查，你可以整理一份精確的日志信息，你也可以發現你不小心修改的文件，給了你一次恢復修改的機會。此外，這是一個審查和仔細察看修改的好機會，你可通過命令**svn status**、**svn diff**和**svn revert**精確地察看所做的修改。你可以使用前兩個命令察看工作拷貝中的修改，使用第三個來撤銷部分（或全部)的修改。 Subversion已經被優化來幫助你完成這個任務，可以在不與版本庫通訊的情況下做許多事情，詳細來說，對于每一個文件，你的的工作拷貝在`.svn`包含了一個“原始的”拷貝，所以Subversion可以快速的告訴你那些文件修改了，甚至允許你在不與版本庫通訊的情況下恢復修改。 #### **svn status** 相對于其他命令，你會更多地使用這個**svn status**命令。 **CVS用戶：控制另類的更新！** 你也許使用**cvs update**來看你做了哪些修改，**svn status**會給你所有你做的改變―而不需要訪問版本庫，并且不會在不知情的情況下與其他用戶作的更改比較。在Subversion，**update**只是做這件事―將工作拷貝更新到版本庫的最新版本，你可以消除使用**update**察看本地修改的習慣。如果你在工作拷貝的頂級目錄運行不帶參數的**svn status**命令，它會檢測你做的所有的文件或目錄的修改，以下的例子是來展示**svn status**可能返回的狀態碼（注意，`#`之后的不是**svn status**打印的）。 ~~~ L abc.c # svn已經在.svn目錄鎖定了abc.c M bar.c # bar.c的內容已經在本地修改過了 M baz.c # baz.c屬性有修改，但沒有內容修改 X 3rd_party # 這個目錄是外部定義的一部分 foo.o # svn并沒有管理foo.o ! some_dir # svn管理這個，但它可能丟失或者不完整 ~ qux # 作為file/dir/link進行了版本控制，但類型已經改變 I .screenrc # svn不管理這個，配置確定要忽略它 A + moved_dir # 包含歷史的添加，歷史記錄了它的來歷 M + moved_dir/README # 包含歷史的添加，并有了本地修改 D stuff/fish.c # 這個文件預定要刪除 A stuff/loot/bloo.h # 這個文件預定要添加 C stuff/loot/lump.c # 這個文件在更新時發生沖突 R xyz.c # 這個文件預定要被替換 S stuff/squawk # 這個文件已經跳轉到了分支 ~~~ 在這種格式下，**svn status**打印五列字符，緊跟一些空格，接著是文件或者目錄名。第一列告訴一個文件的狀態或它的內容，返回代碼解釋如下： `A item` 文件、目錄或是符號鏈`item`預定加入到版本庫。 `C item` 文件`item`發生沖突，在從服務器更新時與本地版本發生交迭，在你提交到版本庫前，必須手工的解決沖突。 `D item` 文件、目錄或是符號鏈`item`預定從版本庫中刪除。 `M item` 文件`item`的內容被修改了。 `R item` 文件、目錄或是符號鏈`item`預定將要替換版本庫中的`item`，這意味著這個對象首先要被刪除，另外一個同名的對象將要被添加，所有的操作發生在一個修訂版本。 `X item` 目錄沒有版本化，但是與Subversion的外部定義關聯，關于外部定義，可以看[“外部定義”一節]( "外部定義")。 ` item` 文件、目錄或是符號鏈`item`不在版本控制之下，你可以通過使用**svn status**的`--quiet`（`-q`）參數或父目錄的`svn:ignore`屬性忽略這個問題，關于忽略文件的使用，見[“`svn:ignore`”一節]( "svn:ignore")。 `! item` 文件、目錄或是符號鏈`item`在版本控制之下，但是已經丟失或者不完整，這可能因為使用非Subversion命令刪除造成的，如果是一個目錄，有可能是檢出或是更新時的中斷造成的，使用**svn update**可以重新從版本庫獲得文件或者目錄，也可以使用**svn revert file**恢復原來的文件。 `~ item` 文件、目錄或是符號鏈`item`在版本庫已經存在，但你的工作拷貝中的是另一個。舉一個例子，你刪除了一個版本庫的文件，新建了一個在原來的位置，而且整個過程中沒有使用**svn delete**或是**svn add**。 `I item` 文件、目錄或是符號鏈`item`不在版本控制下，Subversion已經配置好了會在**svn add**、**svn import**和**svn status**命令忽略這個文件，關于忽略文件，見[“`svn:ignore`”一節]("svn:ignore")。注意，這個符號只會在使用**svn status**的參數`--no-ignore`時才會出現―否則這個文件會被忽略且不會顯示！第二列說明文件或目錄的屬性的狀態（更多細節可以看[“屬性”一節]( "屬性")），如果一個`M`出現在第二列，說明屬性被修改了，否則顯示空白。第三列只顯示空白或者`L`，`L`表示Subversion已經在`.svn`工作區域鎖定了這個項目，當你的**svn commit**正在運行的時候―也許正在輸入log信息，運行**svn status**你可以看到`L`標記，如果這時候Subversion并沒有運行，可以推測Subversion發生中斷并且已經鎖定，你必須運行**svn cleanup**來清除鎖定（本節后面將有更多論述）。第四列只會顯示空白或`+`，`+`的意思是一個有附加歷史信息的文件或目錄預定添加或者修改到版本庫，通常出現在**svn move**或是**svn copy**時，如果是看到`A+`就是說要包含歷史的增加，它可以是一個文件或是拷貝的根目錄。`+`表示它是即將包含歷史增加到版本庫的目錄的一部分，也就是說他的父目錄要拷貝，它只是跟著一起的。 `M+`表示將要包含歷史的增加，并且已經更改了。當你提交時，首先會隨父目錄進行包含歷史的增加，然后本地的修改提交到更改后的版本。第五列只顯示空白或是`S`，表示這個目錄或文件已經轉到了一個分支下了（使用**svn switch**）。如果你傳遞一個路徑給**svn status**，它只給你這個項目的信息： ~~~ $ svn status stuff/fish.c D stuff/fish.c ~~~ **svn status**也有一個`--verbose`（`-v`）選項，它可以顯示工作拷貝中的*所有*項目，即使沒有改變過： ~~~ $ svn status --verbose M 44 23 sally README 44 30 sally INSTALL M 44 20 harry bar.c 44 18 ira stuff 44 35 harry stuff/trout.c D 44 19 ira stuff/fish.c 44 21 sally stuff/things A 0 stuff/things/bloo.h 44 36 harry stuff/things/gloo.c ~~~ 這是**svn status**的“加長形式”，第一列保持相同，第二列顯示一個工作版本號，第三和第四列顯示最后一次修改的版本號和修改人。上面所有的**svn status**調用并沒有聯系版本庫，只是與`.svn`中的元數據進行比較的結果，最后，是`--show-updates`（`-u`）參數，它將會聯系版本庫為已經過時的數據添加新信息： ~~~ $ svn status --show-updates --verbose M * 44 23 sally README M 44 20 harry bar.c * 44 35 harry stuff/trout.c D 44 19 ira stuff/fish.c A 0 stuff/things/bloo.h Status against revision: 46 ~~~ 注意這兩個星號：如果你現在執行**svn update**，你的`README`和`trout.c`會被更新，這告訴你許多有用的信息―你可以在提交之前，需要使用更新操作得到文件`README`的更新，或者說文件已經過時，版本庫會拒絕了你的提交。（后面還有更多關于此主題）。 #### **svn diff** 另一種檢查修改的方式是**svn diff**命令，你可以通過不帶參數的**svn diff***精確的*找出你所做的修改，這會輸出統一區別格式：[[3](#)] ~~~ $ svn diff Index: bar.c =================================================================== --- bar.c (revision 3) +++ bar.c (working copy) @@ -1,7 +1,12 @@ +#include <sys/types.h> +#include <sys/stat.h> +#include <unistd.h> + +#include <stdio.h> int main(void) { - printf("Sixty-four slices of American Cheese...\n"); + printf("Sixty-five slices of American Cheese...\n"); return 0; } Index: README =================================================================== --- README (revision 3) +++ README (working copy) @@ -193,3 +193,4 @@ +Note to self: pick up laundry. Index: stuff/fish.c =================================================================== --- stuff/fish.c (revision 1) +++ stuff/fish.c (working copy) -Welcome to the file known as 'fish'. -Information on fish will be here soon. Index: stuff/things/bloo.h =================================================================== --- stuff/things/bloo.h (revision 8) +++ stuff/things/bloo.h (working copy) +Here is a new file to describe +things about bloo. ~~~ **svn diff**命令通過比較你的文件和`.svn`的“原始”文件來輸出信息，預定要增加的文件會顯示所有增加的文本，要刪除的文件會顯示所有要刪除的文本。輸出的格式為*統一區別格式*（unified diff format），刪除的行前面加一個`-`，添加的行前面有一個`+`，**svn diff**命令也打印文件名和**打補丁**需要的信息，所以你可以通過重定向一個區別文件來生成“補丁”： ~~~ $ svn diff > patchfile ~~~ 舉個例子，你可以把補丁文件發送郵件到其他開發者，在提交之前審核和測試。 #### **svn revert** 假設你通過上面的diff輸出發現你不小心用編輯器在`README`中輸入了一些字符。這是使用**svn revert**的好機會。 ~~~ $ svn revert README Reverted 'README' ~~~ Subversion把文件恢復到未修改的狀態，叫做`.svn`目錄的“原始”拷貝，應該知道**svn revert**可以恢復任何預定要做的操作，舉個例子，你不再想添加一個文件： ~~~ $ svn status foo foo $ svn add foo A foo $ svn revert foo Reverted 'foo' $ svn status foo foo ~~~ ### 注意 **svn revert***`ITEM`*的效果與刪除*`ITEM`*然后執行**svn update -r BASE***`ITEM`*完全一樣，但是，如果你使用**svn revert**它不必通知版本庫就可以恢復文件。或許你不小心刪除了一個文件： ~~~ $ svn status README README $ svn delete README D README $ svn revert README Reverted 'README' $ svn status README README ~~~ **看！沒有網絡！** 這三個命令（**svn status**、**svn diff**和 **svn revert**）都可以在沒有網絡的情況下工作，這讓你在沒有網絡連接時的管理修改過程更加簡單，像在飛機上旅行，乘坐火車往返或是在海灘上奮力工作時。 Subversion通過在`.svn`管理區域使用原始的版本緩存來做到這一點，這使得恢復本地版本而*不必訪問網絡*，這個緩存（叫做“text-base”）也允許Subversion可以根據原始版本生成一個壓縮的增量（“區別”）提交―即使你有個非常快的網絡，有這樣一個緩存有極大的好處，非常的快，只向服務器提交修改的部分，這一點乍一看好像并不重要，但當你要提交一個400M大小的文件的修改時，你就會明白！ ### 解決沖突（合并別人的修改）我們可以使用**svn status -u**來預測沖突，當你運行**svn update**一些有趣的事情發生了： ~~~ $ svn update U INSTALL G README C bar.c Updated to revision 46. ~~~ `U`和`G`沒必要關心，文件干凈的接受了版本庫的變化，文件標示為`U`表明本地沒有修改，文件已經根據版本庫更新。`G`標示合并，標示本地已經修改過，與版本庫沒有重迭的地方，已經合并。但是`C`表示沖突，說明服務器上的改動同你的改動沖突了，你需要自己手工去解決。當沖突發生了，有三件事可以幫助你注意到這種情況和解決問題： - Subversion打印`C`標記，并且標記這個文件已沖突。 - 如果Subversion認為這個文件是可合并的，它會置入*沖突標記*―特殊的橫線分開沖突的“兩面”―在文件里可視化的描述重疊的部分（Subversion使用`svn:mime-type`屬性來決定一個文件是否可以使用上下文的，以行為基礎合并，更多信息可以看[“`svn:mime-type`”一節]( "svn:mime-type")）。 - 對于每一個沖突的文件，Subversion放置三個額外的未版本化文件到你的工作拷貝： `filename.mine` 你更新前的文件，沒有沖突標志，只是你最新更改的內容。（如果Subversion認為這個文件不可以合并，`.mine`文件不會創建，因為它和工作文件相同。） `filename.rOLDREV` 這是你的做更新操作以前的`BASE`版本文件，就是你在上次更新之后未作更改的版本。 `filename.rNEWREV` 這是你的Subversion客戶端從服務器剛剛收到的版本，這個文件對應版本庫的`HEAD`版本。這里`OLDREV`是你的`.svn`目錄中的修訂版本號，`NEWREV`是版本庫中`HEAD`的版本號。舉一個例子，Sally修改了`sandwich.txt`，Harry剛剛改變了他的本地拷貝中的這個文件并且提交到服務器，Sally在提交之前更新它的工作拷貝得到了沖突： ~~~ $ svn update C sandwich.txt Updated to revision 2. $ ls -1 sandwich.txt sandwich.txt.mine sandwich.txt.r1 sandwich.txt.r2 ~~~ 在這種情況下，Subversion*不*會允許你提交`sandwich.txt`，直到你的三個臨時文件被刪掉。 ~~~ $ svn commit --message "Add a few more things" svn: Commit failed (details follow): svn: Aborting commit: '/home/sally/svn-work/sandwich.txt' remains in conflict ~~~ 如果你遇到沖突，三件事你可以選擇： - “手動”合并沖突文本（檢查和修改文件中的沖突標志）。 - 用某一個臨時文件覆蓋你的工作文件。 - 運行**svn revert <filename>**來放棄所有的修改。一旦你解決了沖突，你需要通過命令**svn resolved**讓Subversion知道，這樣就會刪除三個臨時文件，Subversion就不會認為這個文件是在沖突狀態了。 ~~~ $ svn resolved sandwich.txt Resolved conflicted state of 'sandwich.txt' ~~~ #### 手工合并沖突第一次嘗試解決沖突讓人感覺很害怕，但經過一點訓練，它簡單的像是騎著車子下坡。這里一個簡單的例子，由于不良的交流，你和同事Sally，同時編輯了`sandwich.txt`。Sally提交了修改，當你準備更新你的版本，沖突發生了，我們不得不去修改`sandwich.txt`來解決這個問題。首先，看一下這個文件： ~~~ $ cat sandwich.txt Top piece of bread Mayonnaise Lettuce Tomato Provolone <<<<<<< .mine Salami Mortadella Prosciutto ======= Sauerkraut Grilled Chicken >>>>>>> .r2 Creole Mustard Bottom piece of bread ~~~ 小于號、等于號和大于號串是沖突標記，并不是沖突的數據，你一定要確定這些內容在下次提交之前得到刪除，前兩組標志中間的內容是你在沖突區所做的修改： ~~~ <<<<<<< .mine Salami Mortadella Prosciutto ======= ~~~ 后兩組之間的是Sally提交的修改沖突： ~~~ ======= Sauerkraut Grilled Chicken >>>>>>> .r2 ~~~ 通常你并不希望只是刪除沖突標志和Sally的修改―當她收到三明治時，會非常的吃驚。所以你應該走到她的辦公室或是拿起電話告訴Sally，你沒辦法從從意大利熟食店得到想要的泡菜。一旦你們確認了提交內容后，修改文件并且刪除沖突標志。 ~~~ Top piece of bread Mayonnaise Lettuce Tomato Provolone Salami Mortadella Prosciutto Creole Mustard Bottom piece of bread ~~~ 現在運行**svn resolved**，你已經準備好提交了： ~~~ $ svn resolved sandwich.txt $ svn commit -m "Go ahead and use my sandwich, discarding Sally's edits." ~~~ 記住，如果你修改沖突時感到混亂，你可以參考subversion生成的三個文件―包括你未作更新的文件。你也可以使用第三方的合并工具檢驗這三個文件。 #### 拷貝覆蓋你的工作文件如果你只是希望取消你的修改，你可以僅僅拷貝Subversion為你生成的文件替換你的工作拷貝： ~~~ $ svn update C sandwich.txt Updated to revision 2. $ ls sandwich.* sandwich.txt sandwich.txt.mine sandwich.txt.r2 sandwich.txt.r1 $ cp sandwich.txt.r2 sandwich.txt $ svn resolved sandwich.txt ~~~ #### 下注：使用**svn revert** 如果你得到沖突，經過檢查你決定取消自己的修改并且重新編輯，你可以恢復你的修改： ~~~ $ svn revert sandwich.txt Reverted 'sandwich.txt' $ ls sandwich.* sandwich.txt ~~~ 注意，當你恢復一個沖突的文件時，不需要再運行**svn resolved**。現在我們準備好提交修改了，注意**svn resolved**不像我們本章學過的其他命令一樣需要參數，在任何你認為解決了沖突的時候，只需要小心運行**svn resolved**，―一旦刪除了臨時文件，Subversion會讓你提交這文件，即使文件中還存在沖突標記。 ### 提交你得修改最后！你的修改結束了，你合并了服務器上所有的修改，你準備好提交修改到版本庫。 **svn commit**命令發送所有的修改到版本庫，當你提交修改時，你需要提供一些描述修改的*日志信息*，你的信息會附到這個修訂版本上，如果信息很簡短，你可以在命令行中使用`--message`（`-m`）選項： ~~~ $ svn commit --message "Corrected number of cheese slices." Sending sandwich.txt Transmitting file data . Committed revision 3. ~~~ 然而，如果你把寫日志信息當作工作的一部分，你也許會希望通過告訴Subversion一個文件名得到日志信息，使用`--file`選項： ~~~ $ svn commit --file logmsg Sending sandwich.txt Transmitting file data . Committed revision 4. ~~~ 如果你沒有指定`--message`或者`--file`選項，Subversion會自動地啟動你最喜歡的編輯器（見[“config”一節]( "config")的`editor-cmd`部分）來編輯日志信息。 ### 提示如果你使用編輯器撰寫日志信息時希望取消提交，你可以直接關掉編輯器，不要保存，如果你已經做過保存，只要簡單的刪掉所有的文本并再次保存。 ~~~ $ svn commit Waiting for Emacs...Done Log message unchanged or not specified a)bort, c)ontinue, e)dit a $ ~~~ 版本庫不知道也不關心你的修改作為一個整體是否有意義，它只檢查是否有其他人修改了同一個文件，如果別人*已經*這樣做了，你的整個提交會失敗，并且提示你一個或多個文件已經過時了： ~~~ $ svn commit --message "Add another rule" Sending rules.txt svn: Commit failed (details follow): svn: Out of date: 'rules.txt' in transaction 'g' ~~~ 此刻，你需要運行**svn update**來處理所有的合并和沖突，然后再嘗試提交。我們已經覆蓋了Subversion基本的工作周期，還有許多其它特性可以管理你得版本庫和工作拷貝，但是只使用前面介紹的命令你就可以很輕松的工作了。當然沒有任何東西是在版本庫里被刪除了―只是在版本庫的`HEAD`里消失了，你可以通過檢出（或者更新你的工作拷貝）你做出刪除操作的前一個修訂版本來找回所有的東西。 Subversion使用內置區別引擎，缺省情況下輸出為統一區別格式。如果你期望不同的輸出格式，你可以使用`--diff-cmd`指定外置的區別程序，并且通過`--extensions`傳遞其他參數，舉個例子，察看本地文件`foo.c`的區別，同時忽略空格修改，你可以運行**svn diff --diff-cmd /usr/bin/diff --extensions '-bc' foo.c**。你也可以手工的刪除這三個臨時文件，但是當Subversion會給你做時你會自己去做嗎？我們是這樣想的。如果你向他們詢問，他們非常有理由把你帶到城外的鐵軌上。