jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peeter Piegaze" <peeter.pieg...@day.com>
Subject Re: Versioning
Date Tue, 14 Aug 2007 21:29:19 GMT
On 8/14/07, Ishai Borovoy <ishaiborovoy@gmail.com> 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 <ishaiborovoy@gmail.com> 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

Mime
View raw message