創建自己的版本庫
svnadmin create –fs-type fsfs /home/lmzhang/myrepos.
svn ci -m “”
關于內置版本號.
HEAD - 最新版本號.
BASE - 當前工作版本的未修改版本.
COMMITTED - BASE - 1
PREV - COMMITTED - 1
svn merge 的作用可以用語在任何兩個版本之間的差異合并到某個工作版本的功能.
語法如下
舉例來說我有一個工作copy，內有一個1.txt 當前版本號是1.
內容是 first.
然后我添加為 first second. svn ci -m “”.
然后我執行 svn merge -r HEAD:PREV 1.txt , svn將比較 HEAD版本和PREV版本的內容差異，然后將這個差異合并到 當前路徑下的1.txt , 由于差異是減少了 second , 因此相當于回到了 版本1.
svn merge的語法允許非常靈活的指定參數，如下是一些例子：
$ svn merge http://svn.example.com/repos/branch1@150 \
http://svn.example.com/repos/branch2@212 \
my-working-copy
$ svn merge -r 100:200 http://svn.example.com/repos/trunk my-working-copy
$ svn merge -r 100:200 http://svn.example.com/repos/trunk
第一種語法使用URL@REV的形式直接列出了所有參數，第二種語法可以用來作為比較同一個URL的不同版本的簡略寫法，最后一種語法表示工作拷貝是可選的，如果省略，默認是當前目錄。
svn 的分支創建倒是很容易.
svn copy from to , 那么to就成為了from的一個copy，在svn的概念中就是分支或者tag.
問題在于合并.
svn 的概念中，分之合并實際上是將某個分之某個版本到另外一個版本之間的變化合并到某個目錄的概念.
比如 分支 b-1 從開始分支的版本 4 , 到做了修改后的版本 9 . 想合并到主干上.
// 下面說明了，為什么要用上面這種做法，僅僅比較帶合并的分支的信息.
(
但是要哪兩個樹進行比較呢？乍一看，回答很明確，只要比較最新的主干與分支。但是你要意識到—這個想法是錯誤的，傷害了許多新用戶！因為svn merge的操作很像svn diff，比較最新的主干和分支樹不僅僅會描述你在分支上所作的修改，這樣的比較會展示太多的不同，不僅包括分支上的增加，也包括了主干上的刪除操作，而這些刪除根本就沒有在分支上發生過。
)
另外通過同一分支上的版本間merge可以執行反向操作，比如版本5對于版本4的修改是完全錯誤的，那么可以通過 svn merge -r 5:4 file.cpp working-copy 來達到在working-copy 中取消這個修改.
反向操作另外一個作用，加入你刪除了head版本中的test.cpp , 但是又想找回來，那么你可以 svn log -v 察看test.cpp 是什么時候被刪除的., -r 10 , 上一個版本 8 . 那么可以執行如下
svn merger -r 10:8 file:///…/ working-copy 就還原了.
當然svn copy -r 也可以.
還有一種方式就是兩個分支間直接進行合并.
另外merge 有一個有用的參數，–dry-run 表示僅僅模擬本次合并的效果，實際上并不生效.
舉例來說
就表示將主干 v1 到分支b_1 v4 之間的差別進行列舉合并到當前工作目錄.
tag 本身和branch在svn 中的操方式是一樣的，不過tag還有一個增強點，就是能夠將當前工作目錄直接進行tag.
update 狀態
U foo
文件foo更新了（從服務器收到修改）。
A foo
文件或目錄foo被添加到工作拷貝。
D foo
文件或目錄foo在工作拷貝被刪除了。
R foo
文件或目錄foo在工作拷貝已經被替換了，這是說，foo被刪除，而一個新的同樣名字的項目添加進來，它們具有同樣的名字，但是版本庫會把它們看作具備不同歷史的不同對象。
G foo
文件foo接收到版本庫的更改，你的本地版本也已經修改，但改變沒有互相影響，Subversion成功的將版本庫和本地文件合并，沒有發生任何問題。
C foo
文件foo的修改與服務器沖突，服務器的修改與你的修改交迭在一起，不要恐慌，這種沖突需要人（你）來解決，我們在后面的章節討論這種情況。
svn status
L some_dir # svn已經在.svn目錄鎖定了some_dir
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 # 這個文件在更新時發生沖突
C stuff/loot/glub.c # 文件在更新時發生屬性沖突
R xyz.c # 這個文件預定要被替換
S stuff/squawk # 這個文件已經跳轉到了分支
K dog.jpg # 文件在本地鎖定；有鎖定令牌
O cat.jpg # 文件在版本庫被其他用戶鎖定
B bird.jpg # 文件本地鎖定，但鎖定發生錯誤
T fish.jpg # 文件本地鎖定，但鎖定丟失
第一列
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”一節。
! 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 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也有一個–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中的元數據進行比較的結果，最后，是–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的更新，或者說文件已經過時，版本庫會拒絕了你的提交。
輸出的格式為統一區別格式（unified diff format），刪除的行前面加一個-，添加的行前面有一個+，svn diff命令也打印文件名和打補丁需要的信息，所以你可以通過重定向一個區別文件來生成“補丁”：
$ svn diff > patchfile
舉個例子，你可以把補丁文件發送郵件到其他開發者，在提交之前審核和測試。
如果你只是希望檢查一個過去的版本而不希望察看它們的區別，使用svn cat：
$ svn cat --revision 2 rules.txt
Be kind to others
Freedom = Chocolate Ice Cream
Everything in moderation
Chew with your mouth open
$
你可以重定向輸出到一個文件：
$ svn cat --revision 2 rules.txt > rules.txt.v2
除了以上的命令，你可以使用帶參數--revision的svn update和svn checkout來使整個工作拷貝“回到過去”[7]：
$ svn checkout --revision 1729 # Checks out a new working copy at r1729
…
$ svn update --revision 1729 # Updates an existing working copy to r1729
…
# 建立庫
$ svnadmin create /usr/local/svn/newrepos
# 建立分支
建立一個備份只是傳遞兩個目錄參數到svn copy命令：
$ cd bigwc
$ svn copy trunk branches/my-calc-branch
$ svn status
A + branches/my-calc-branch
現在，我們必須告訴你建立分支最簡單的方法：svn copy可以直接對兩個URL操作。
$ svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Creating a private branch of /calc/trunk."
Committed revision 341.
鎖定-修改-解鎖問題
我們有兩個共同工作者，Harry和Sally，他們想同時編輯版本庫里的同一個文件，如果首先Harry保存它的修改，過了一會，Sally可能湊巧用自己的版本覆蓋了這些文件，Harry的更改不會永遠消失（因為系統記錄了每次修改），Harry所有的修改不會出現在Sally的文件中，所以Harry的工作還是丟失了—至少是從最新的版本中丟失了—而且是意外的，這就是我們要明確避免的情況！
在這種情況下，我們應該明確對需要進行修改的目錄進行鎖定.
拷貝-修改-合并模型假定文件是可以根據上下文合并的：就是版本庫的文件主要是以行為基礎的文本文件（例如程序源代碼）。但對于二進制格式，例如藝術品或聲音，在這種情況下，十分有必要讓用戶輪流修改文件，如果沒有線性的訪問，有些人的許多工作就最終要被放棄。
copy-edit-merge
原文：http://www.alisdn.com/wordpress/?p=1381