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使用“拷贝-编辑-合并”模式，这样每次从关系数据库中检索数据时不再要求锁定目标表了。