subversion早期版本的刪除
最近乙個版本管理伺服器發生了硬碟空間不夠的問題。調查結果是其中乙個版本庫居然有47g，佔據了大部分的伺服器硬碟空間。經過跟使用的公司協商，決定採用刪除版本庫早期履歷的方式縮減版本庫尺寸。
具體作業過程如下：
準備工作
停止apache伺服器，修改版本庫目錄路許可權為root的方式，阻止所有的使用者使用該版本庫。重啟apache，這樣可保證其他版本庫的使用者繼續使用。
備份原有版本庫。
版本庫全備份可以採用svnadmin dump和svnadmin hotcopy兩種方法。在整個過程中兩種方法都會用到。首先作為版本庫全備份，以防將來出現作業錯誤時可以立刻恢復原有版本庫的操作，建議使用svnadmin hotcopy。一方面這樣的備份速度比較快，另一方面備份的結果就是乙個可以立刻使用的版本庫，在需要恢復的時候直接拷貝回去就行了。具體命令如下：
svnadmin hotcopy --clean-logs /path/to/repo ./hotcopy >hotcopy.log 2>hotcopy_err.log &
備份的結果就是乙個目錄，尺寸基本和原版本庫相同，47g。
dump版本庫需要保留的版本。
通過svnlook youngest /path/to/repo命令可以看到版本庫最後的版本是多少。我要作業的版本庫是14079。經過跟對方公司協商，決定保留10000到14079之間的版本。因此需要從版本庫把10000以後的版本dump出來。具體命令如下
svnadmin dump /path/to/repo -r 10000:14079 > repo_dump_10000-14079.dmp 2>repo_dump_10000-14079.log &
dump出來的檔案大約34g。
檢視一下日誌檔案，確定所需要的版本都被正確的dump下來了。
重建版本庫
rm -rf /path/to/repo
svnadmin create /path/to/repo
注意這裡面沒有使用 --fs-type bdb引數，因此建立出來的版本庫是fsfs後端的。後面還會繼續解釋為什麼這麼做。
重新匯入新版本
svnadmin load /path/to/repo < repo_dump_10000-14079.dmp > repo_load.log 2>repo_load_err.log &
檢查一下日誌檔案，看看load是否成功。用svnlook命令看看load以後版本庫的最新版本。
修改版本庫許可權
chown -r apache:apache /path/to/repo
到此為止版本庫的歷史版本刪除工作就結束了。需要注意的是，新建出來的版本庫的最新版本應該是4080。另外，經過觀察，新建立出來的版本尺寸只有2.7g。這個結果曾經一度讓我懷疑load沒有成功。但是事實上確實如此。需要說明的是，原來那個佔了47g的版本庫就是bdb格式的。我又試著建立了乙個bdb後端的版本庫，用同樣的方式把dump檔案導進去，結果版本庫的尺寸接近30g。而且匯入的速度來看也明顯比向fsfs後端版本庫匯入要慢很多。大概多了乙個多小時的時間。可見bdb後端和fsfs後端版本庫在某種情況下的尺寸差距驚人的大。手冊是雖然也說了fsfs會比bdb小一些，但是絕對沒想到會小那麼多。subversion現在主推fsfs格式是有道理的。但是我總覺得畢竟bdb歷史更悠久一些，也更穩定一些。所以在今後硬碟空間不緊張的前提下，我還是傾向於使用bdb後端格式。
Subversion 版本管理
最近用了subversion,感覺不錯.來個walkthrough吧 先建乙個專案叫 my project svn mkdir svn 再把這個專案check out到本地當前目錄,別忘了那一點 svn co svn 在本地搗鼓你的專案,如此這搬 my project src main src te...
Subversion版本控制資訊的清除
有時候，你可能得到乙份 裡面含有很多的.svn目錄，這就是subversion的版本控制資訊儲存的目錄，如果你只想要源 樹，你就得想麼辦法來清除它們。你可以有很多種方法來實現，這裡提供一種基於windows命令列指令碼的實現。setlocal set startdir cd set a folder...
版本控制系統Subversion
系統提供撤銷的功能對我們實際開發中特別重要。改動後撤銷幾乎也是我們每個人經常做的事情。再多人進行同乙個專案的開發或者測試的時候，版本的唯一性 類似於臨界區資源 也就是說a 和 b 兩個人協同工作的時候不能同時對同乙個檔案改動，並儲存成功。否則就會出現不一致問題。版本控制系統很好的解決了這一問題，並且...