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 属性, 待续