OK, thanks. Peeter Piegaze-2 wrote: > > 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 > >
-- View this message in context: http://www.nabble.com/Versioning-tf4267048.html#a12156359 Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
