深入剖析SVN文檔要點
本節和大家一起學習一下SVN文檔的要點，在學習SVN的過程中你可能會遇到SVN問題，于是和大家分享一下，看完本文你肯定有不少收獲，希望本文能教會你更多東西，歡迎打擊一起來學習SVN文檔方面的知識。
1.Subversion可以告訴我們工作文件是處于如下四種狀態的那一種：
SVN文檔未修改且是當前的
文件在工作目錄里沒有修改，在工作修訂版本之后沒有修改提交到版本庫。svncommit操作不做任何事情，svnupdate不做任何事情。
本地已修改且是當前的
在工作目錄已經修改，從基本修訂版本之后沒有修改提交到版本庫。本地修改沒有提交，因此svncommit會成功提交，svnupdate不做任何事情。
SVN文檔未修改且不是當前的了
這個文件在工作目錄沒有修改，但在版本庫中已經修改了。這個文件最終將更新到***版本，成為當時的公共修訂版本。svncommit不做任何事情，svnupdate將會取得***的版本到工作拷貝。
SVN文檔本地已修改且不是***的
這個文件在工作目錄和版本庫都得到修改。一個svncommit將會失敗，這個文件必須首先更新，svnupdate命令會合并公共和本地修改，如果Subversion不可以自動完成，將會讓用戶解決沖突。
這看起來需要記錄很多事情，但是svnstatus命令可以告訴你工作拷貝中文件的狀態，關于此命令更多的信息，請看“查看你的修改概況”一節
2.混合修訂版本的工作拷貝
作為一個普遍原理，Subversion努力做到盡可能的靈活，一個特殊的靈活特性就是讓工作拷貝包含不同工作修訂版本的文件和目錄，不幸的是，這個靈活性會讓許多新用戶感到迷惑。如果上一個混合修訂版本的例子讓你感到困惑，這里是一個為何有這種特性和如何利用這個特性的基礎介紹。
SVN文檔更新和提交是分開的
Subversion有一個基本原則就是一個“推”動作不會導致“拉”，反之亦然，因為你準備好了提交你的修改并不意味著你已經準備好了從其他人那里接受修改。如果你的新的修改還在進行，svnupdate將會優雅的合并版本庫的修改到你的工作拷貝，而不會強迫將修改發布。
這個規則的主要副作用就是工作拷貝需要記錄額外的信息來追蹤混合修訂版本，并且也需要能容忍這種混合，當目錄本身也是版本化的時候情況更加復雜。
舉個例子，假定你有一個工作拷貝，修訂版本號是10。你修改了foo.html，然后執行svncommit，在版本庫里創建了修訂版本15。當成功提交之后，許多用戶希望工作拷貝完全變成修訂版本15，但是事實并非如此。修訂版本從10到15會發生任何修改，可是客戶端在運行svnupdate之前不知道版本庫發生了怎樣的改變，svncommit不會拖出任何新的修改。另一方面，如果svncommit會自動下載***的修改，可以使得整個工作拷貝成為修訂版本15—但是，那樣我們會打破“push”和“pull”完全分開的原則。因此，Subversion客戶端最安全的方式是標記一個文件—foo.html—為修訂版本15，工作拷貝余下的部分還是修訂版本10。只有運行svnupdate才會下載***的修改，整個工作拷貝被標記為修訂版本15。本節關于SVN文檔方面的知識講解完畢。
【編輯推薦】
