Java 企业级项目中应用 Subversion 的配置与管理

  企业最重要的资产应该是数据信息，但现在的企业应用除了需要存储数据外，还经常要

求跟踪数据变化整个过程，并会扩展到一系列相关的要求，如数据变化的原因、变化的时

间等，而且在许多情况下是对以文档形式存储的数据进行跟踪。使用 SubVersion 可以满足

这些貌似普通但实际上很复杂的要求

    

 

来自数据的挑战

    企业应用存储了关键数据，而且应用程序并不仅限于对数据进行插入、读取、更新和删

除操作（即 CRUD），应用程序还期望能够存储数据更改的历史记录。此外，企业按照一

系列的业务或者规定的要求，不但要求存储数据资产更改结果的历史，而且要求存储是

谁，在什么时候，因为什么原因，如何改变了数据等等诸如此类的跟踪信息。

    应用数据的形式和尺寸也有很多变数，既有简单数据，如字符串和数字型，也有复杂

的类型，如使用 Blob 或 Cblob 类型来存储文档。典型的应用程序要处理大量的上传给程序

处理的以文档形式存储的数据，如果用传统的历史表等方式来跟踪诸如复杂类型的文档

的变化，简直就是做一场恶梦。

    使用历史表进行跟踪

    关系数据库是存储数据的首选，可以高效地组织、存储、检索数据信息，由于应用程序

将数据存放在关系数据库中，当然就顺理成章的尝试用它来存放历史跟踪数据，一般是

使用带有时间戳的数据表来存放所有的重要数据表。在更新主表的时候会把旧数据推入历

史表中，这个过程一般是通过触发器或由应用程序自己来完成。

    使用历史表存储历史信息，会存在以下问题：

    .关系型数据库和关系模型会提高数据存储和检索的效率，但是历史表显然不适合使用

 

关系型数据库。

    .数据库不支持版本控制。应用程序不得不使用触发器或其它定制的技术来仔细的存放

 

数据（，以便实现版本控制功能）。

    .必须由应用程序亲自检测版本之间的变化，从历史表中检索历史数据进行互相比较。

    关系数据库依旧是存储和检索业务数据的仓库，它们擅长于管理数据。以上列举的缺

点仅限于用关系数据模型存储多个不同的版本的数据并进行历史数据跟踪的情况下。

    Subversion   

和 JavaSVN