Java 企業級項目中應用Subversion的配置與理
--JavaSVN + Subversion跟蹤數據變化歷史
譯者：陳海青(http://www.chq.name)
企業重要的資產應該是數據信息，但現在的企業應用除了需要存儲數據外，還經常要求跟蹤數據變化整個過程，并會擴展到一系列相關的要求，如數據變化的原因、變化的時間等，而且在許多情況下是對以文檔形式存儲的數據進行跟蹤。使用SubVersion可以滿足這些貌似普通但實際上很復雜的要求
版權聲明：任何獲得Matrix授權的網站，轉載時請務必保留以下作者信息和鏈接
作者:陳海青(http://www.chq.name);michaelzyy
原文:http://www.matrix.org.cn/resource/article/2007-02-05/Subversion_ba84f1b9-b4b0-11db-b1a9-1f2330fc56f8.html
關鍵字:Java;Subversion
來自數據的挑戰
企業應用存儲了關鍵數據，而且應用程序并不于對數據進行插入、讀取、更新和刪除操作（即CRUD），應用程序還期望能夠存儲數據更改的歷史記錄。此外，企業按照一系列的業務或者規定的要求，不但要求存儲數據資產更改結果的歷史，而且要求存儲是誰，在什么時候，因為什么原因，如何改變了數據等等諸如此類的跟蹤信息。
應用數據的形式和尺寸也有很多變數，既有簡單數據，如字符串和數字型，也有復雜的類型，如使用Blob或Cblob類型來存儲文檔。典型的應用程序要處理大量的上傳給程序處理的以文檔形式存儲的數據，如果用傳統的歷史表等方式來跟蹤諸如復雜類型的文檔的變化，簡直是做一場惡夢。
使用歷史表進行跟蹤
關系數據庫是存儲數據的，可以高效地組織、存儲、檢索數據信息，由于應用程序將數據存放在關系數據庫中，當然順理成章的嘗試用它來存放歷史跟蹤數據，一般是使用帶有時間戳的數據表來存放所有的重要數據表。在更新主表的時候會把舊數據推入歷史表中，這個過程一般是通過觸發器或由應用程序自己來完成。
使用歷史表存儲歷史信息，會存在以下問題：
+關系型數據庫和關系模型會提高數據存儲和檢索的效率，但是歷史表顯然不適合使用關系型數據庫。
+數據庫不支持版本控制。應用程序不得不使用觸發器或其它定制的技術來仔細的存放數據（，以便實現版本控制功能）。
+必須由應用程序親自檢測版本之間的變化，從歷史表中檢索歷史數據進行互相比較。
關系數據庫依舊是存儲和檢索業務數據的倉庫，它們擅長于管理數據。以上列舉的缺點于用關系數據模型存儲多個不同的版本的數據并進行歷史數據跟蹤的情況下。
Subversion 和 JavaSVN
Subversion是一個可以代替CVS（一個傳統的版本控制系統）的版本控制系統。Subversion使用稱作倉庫的樹狀結構來存儲文件和目錄。Subversion會跟蹤對倉庫中信息的所有改變，它具有一個中央倉庫，允許進行并發更新，允許通過http或https使用WebDAV協議來訪問倉庫，可以避免使用過程中的防火墻的干擾。Subversion的理念是“拷貝-編輯-合并”，這意味著在修改時不需要鎖定被修改的對象。
（譯者注：關于WebDAV，是Web-based Distributed Authoring and Versioning的縮寫，是一個標準HTTP協議的擴展，通過web技術把目錄和文件作為可讀些的對象進行共享讀寫，把web變成一個可讀寫的媒體。RFCs2518和3253描述了WebDAV/DeltaV 對于HTTP的擴展，網址http://www.webdav.org/。）
JavaSVN是一個純Java的Subversion客戶端類庫，提供與Subversion交互的基于Java程序的應用程序接口(API)， JavaSVN既提供了進行直接讀取Subversion倉庫的底層接口，也提供了從Subversion倉庫檢出工作拷貝的高層接口。
現在，應用程序可以使用結合了關系型數據庫和Subversion的方式來滿足數據存儲和變化跟蹤的需求了，對數據庫的更新同時會將變化情況提交到Subversion中，Subversion將是記錄變化的主要數據源，關系數據庫則用于除此以外所有的其他存儲。這樣做還有一個優勢，由于Subversion使用“拷貝-編輯-合并”模式，這樣每次從關系數據庫中檢索數據時不再要求鎖定目標表了。
