On 8/14/07, Ishai Borovoy <[EMAIL PROTECTED]> wrote: > > Thanks. > Regarding question number 2, I will try to explain with an example: > suppose we have one version a', and there are other versions b', c'. > When a' is changed and other condition occurs (for example the person who > changed a' version is x), then b', c' need to get updated with the changes > in a'? > Is that possible to implement with the current versioning of JackRabbit?
Ok, first let's get the terminology straight: Versions are the frozen things in the version storage. They are created every time a versionable node is checked-in. A Version itself cannot be changed. Its versionable can be changed and then checked-in again, creating a new version, for example, as a successor of the previous one. "Update" in JCR refers to particular inter-workspace operation: copying the state of a node in workspace A to its corresponding node in workspace B (see Node.update) I don't think this is what you mean is it? So given the above carifications I *think* you are asking this: - You have three nodes A, B and C - You make a change to A and check it in, thus creating a new version of A (call it A') - You are asking if there is some configuration that can be set that will automatically cause the same changes to be made to both B and C and then checkin both. The answer to that is no. Of course your app can do whatever it likes but there is no JCR-level function that does this. Sorry if I have mischaracterized your question. Is this what you are asking? BTW, I recommend that you read the spec. There's a lot of info there that might help you. Cheers, Peeter > > Peeter Piegaze-2 wrote: > > > > Hi Ishai, > > > > On 8/14/07, Ishai Borovoy <[EMAIL PROTECTED]> wrote: > >> > >> Hi, > >> We need to implement versioning module. I have some question about it: > >> > >> (Our jackrabbit version is 1.3.1) > >> > >> 1. Can we set the label (custom label)in checkin? > > No, setting and changing a label is done though the > > VersionHistory.addVersionLabel and VersionHistory.removeVersionLabel > > methods. Thes methods take an existing version name and therefore that > > version must already exist in the VH. > > > >> 2. Can we force in some case changes in one version to influence (update) > >> other versions? > > I'm not sure exacly what you mean here. > > > >> 3. Is there any performance issues to work with versions (for example > >> indexing)? > >> 4. What is the main differences between JSR-170 and JSR-283? > > 283 is not finalized but the current draft does include some new > > features around versioning, but it does not introduce incompatible > > changes. The public review draft of 283 is available here: > > http://jcp.org/aboutJava/communityprocess/pr/jsr283/ > > > > If you are interested you can read it and send comments to the address > > listed on that page > > > > Cheers, > > Peeter > > > > > > > > > >> > >> Thanks, > >> Ishai > >> > >> > >> -- > >> View this message in context: http://www.nabble.com/Versioning-tf.html#a > >> Sent from the Jackrabbit - Users mailing list archive at Nabble.com. > >> > >> > > > > > > -- > > Peeter Piegaze > > > > Day Software > > Suite 331 > > 67 Mowat Avenue > > Toronto Ontario M6K 3E3 > > Canada > > > > office > > mobile > > fax > > > > > > -- > View this message in context: > http://www.nabble.com/Versioning-tf4267048.html#a12151819 > Sent from the Jackrabbit - Users mailing list archive at Nabble.com. > > -- Peeter Piegaze Day Software Suite 331 67 Mowat Avenue Toronto Ontario M6K 3E3 Canada office +1 416 987 5720 mobile +1 647 205 2403 fax +1 866 719 3988
