理解Jackrabbit中的Version机制

1. 一个会产生Version的节点，它的Node Type 一定包含有 mix:versionable。在Jackrabbit里面，只有实现了mix:versionable的Node 才可以做checkin/checkout的操作。

2. 要让一个Node产生新的Version, 你做的第一步应当是checkout, 然后修改其中的各个属性，然后是checkin。 在Jackrabbit的定义文件里面，一个支持Version的节点一定有一个属性叫做 jcr:isCheckout, 他的默认值是true

3. 我们都知道，Node 在 Jackrabbit是一个树形的结构，而Node 的 Version 和 Node 的存储方式有很大的不同。在Jackrabbit里面，每一个支持Version的 Node 都有一个 jcr:versionHistory 属性。这个属性值是一个引用(reference)， 它就指向存在于 version storage 里面的 version history 节点。而version history 的存储可以说是平面的，类似于key-value的存储方式，key存在于node 上， 而value存储于 version storage 里面。

4. 以下是一个Version History的示意图。

<script type="text/javascript"> </script> <script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"></script>

* jcr:rootVersion
*  |     |
* 1.0   2.0
*  |
* 1.1
*  |
* 1.2 ---/  ------/
*  |      /        /
* 1.3   1.2.0   1.2.0.0
*  |      |
* 1.4   1.2.1 ----/
*  |      |        /
* 1.5   1.2.2   1.2.1.0
*  |      |        |
* 1.6     |     1.2.1.1
*  |-----/
* 1.7

让人感觉意外的是如何会产生 1.2.0 或者是 1.2.0.0呢。如果不是特别明白，继续往下看。

5. 如果一个节点要恢复成以前的一个版本会发生什么情况呢。实际上这一点并不能，调用Node.restore() 可以让一个版本恢复到指定的一个版本。假定现在Node有两个版本如下：

* jcr:rootVersion
*  |
* 1.0
*  |
* 1.1

这时，我将版本恢复到1.0，便会产生一个新的版本号， 如下

* jcr:rootVersion
*  |
* 1.0
*  |
* 1.1 ---/
*  |      /       
* 1.2   1.1.0  

是的，这样子第4里面的疑惑已经知道的差不多了，但是2.0是怎么来的呢?

6. Version 里面还有个概念叫做 Version label, 它是用来快速定位 一个Version History 里面的 Version  的。

你可以通过 vh.getVersionByLabel(label) 快速拿到一个Version, 而不需要通过skip方法去拿。

7. 2.0是一种什么情况呢。如果有两个workspace, 会出现2.0的情况。 workspace的node version 不同步时，则可以通过 node.merge或是node.update来使得这两个workspace里面的Node 一致。用 node.merge方法时，如果两个workspace里面的version的版本的branch已经不一样时，目标workspace中的node会为另一个workspace的node 建一个新的branch, 这个Branch就是 2.0

8. onParentVersion 属性, 待续