Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <7919c1900708150541q65111535x2c9623b7733d1efd@mail.gmail.com>
Date: Wed, 15 Aug 2007 08:41:00 -0400
From: "Peeter Piegaze" <peeter.piegaze@day.com>
Sender: ppiegaze@day.com
To: users@jackrabbit.apache.org
Subject: Re: Versioning
In-Reply-To: <12156446.post@talk.nabble.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <12143709.post@talk.nabble.com>
	 <7919c1900708140851l2da69252g5a0b16dc02f33c44@mail.gmail.com>
	 <12151819.post@talk.nabble.com>
	 <7d3e1a010708141541o148ec676tdca33b318f1ea7a3@mail.gmail.com>
	 <12156446.post@talk.nabble.com>

Ishai,

Variants as you describe them seem to map most closely to the concept
of corresponding nodes in JCR.

In JCR a referenceable node is identified by its UUID. Another node in
another workspace with the same UUID is its corresponding node. It
shares idenitity but not necessarily state. Transfer of state from
node to node across WS is done through Node.update.

This may be what you are looking for. However, from your description
it may be overkill to devote a WS to each variant. If that is the case
then the obvious alternative is to create the variant relation at the
application level.

On 8/15/07, Ishai Borovoy <ishaiborovoy@gmail.com> wrote:
>
> Hi Brian,
> We try to think of some way to create variants in our system. the
> terminology of variants is little bit difference from versioning in our
> case.  The thing is that we need to save some root (basic node), and let
> user create from it different variants, but also give them the ability to
> name this variant, to update it, and get changes from other variant in some
> conditions. what I want to check is if the versioning could be good
> option/solution for that, it looks like from what I read so far in the specs
> (170 & 283) and from what I read here that we need to force the versioning
> for that :,( , so maybe we need to implement it in a different way?
>
> But we never say never so we still check the option... :working:
>
>
> Brian Thompson-5 wrote:
> >
> > Out of curiosity, why would you want to make changes to version nodes?
> > Isn't keeping a record of past changes exactly the point of having
> > versioning in the first place?
> >
> > -Brian
> >
> >
> >
> > 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?
> >>
> >>
> >> 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.
> >>
> >>
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Versioning-tf4267048.html#a12156446
> 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