You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Paco Avila <pa...@git.es> on 2006/06/19 13:29:31 UTC

Questions about versioning

I am using versioning in Jackrabbit and I have some questions. The
JSR-170 especification is not very clear for me.

Imagine I have a two users. Both are loged in the repository and
performs some actions. I have an test code that runs like this:

-> User A logs into the system
-> User B logs into the system
-> User A add a new versionable node.
-> User A performs a checkout of this document
-> User B modify this node content and performs a checkin.

This test runs ok, but I have some questions:

- If the user A performs a Checkout, why can user B modify and checkin?
- Do the A user have to lock himself the node?
- If the user B can modify and perform a checkin, what happends if
meanwhile user A modify the node? In my test, the last modification
(user A) is versioned, and the user B modification (performed before
user A modification) is lost. Is this ok?

So, if all these is fine I have to do something like this:

-> User A lock node
-> User A performs checkout
-> User A modify node
-> User A performs checkin
-> User A unlock node

isn't it?

-- 
Administrador de la Guía Ubuntu
http://www.guia-ubuntu.org


Re: Questions about versioning

Posted by Paco Avila <pa...@git.es>.
El lun, 19-06-2006 a las 13:45 +0200, Tobias Bocanegra escribió:

> > So, if all these is fine I have to do something like this:
> >
> > -> User A lock node
> > -> User A performs checkout
> > -> User A modify node
> > -> User A performs checkin
> > -> User A unlock node
> >
> > isn't it?
> correct.
> 
> if you don't want to use locking, you can create several workspaces
> for you users. for example workspace A for user A, and workspace B for
> user B:
> 
> - User A logs into workspace A
> - User B logs into workspace B
> - A does a checkout of Node N
> - B does a checkout of Node N
> - A modifies N and does checkin -> version 1.1
> - B modifies N and does checkin -> version 1.0.1 (new branch, since
> 1.1 already exists)

It sounds very interesting, but just locking is fine for now :) 

Thanks!
-- 
Paco Avila <pa...@git.es>


Re: Questions about versioning

Posted by Shanmugam Gopal <ha...@hotmail.com>.
Dear All,

With reference to Jackrabbit versioning, I have some questions.

Let us assume that the version history of a node is something like
1.1, 1.2, 1.3, 1.4(current version).

Now from version 1.4, it is restored to version 1.2 using restore method of 
javax.jcr.Node.
After making one more change to this node, the next version becomes 1.3.1 ?

It is very confusing...!!!!  Do you people think is it correct behaviour ?

And, Is it possible to have versioning sequence like 1, 2, 3, 4......etc,
instead of 1.1, 1.2, 1.3.....etc.

Regards,
Shan


>From: "Tobias Bocanegra" <to...@day.com>
>Reply-To: tobias.bocanegra@day.com
>To: dev@jackrabbit.apache.org
>Subject: Re: Questions about versioning
>Date: Mon, 19 Jun 2006 13:45:00 +0200
>
>hi paco,
>please note, that versioning has nothing to do with locking.
>
>>- If the user A performs a Checkout, why can user B modify and checkin?
>becauses it's not locking....
>
>>- Do the A user have to lock himself the node?
>yes.
>
>>- If the user B can modify and perform a checkin, what happends if
>>meanwhile user A modify the node? In my test, the last modification
>>(user A) is versioned, and the user B modification (performed before
>>user A modification) is lost. Is this ok?
>yes.
>
>>So, if all these is fine I have to do something like this:
>>
>>-> User A lock node
>>-> User A performs checkout
>>-> User A modify node
>>-> User A performs checkin
>>-> User A unlock node
>>
>>isn't it?
>correct.
>
>if you don't want to use locking, you can create several workspaces
>for you users. for example workspace A for user A, and workspace B for
>user B:
>
>- User A logs into workspace A
>- User B logs into workspace B
>- A does a checkout of Node N
>- B does a checkout of Node N
>- A modifies N and does checkin -> version 1.1
>- B modifies N and does checkin -> version 1.0.1 (new branch, since
>1.1 already exists)
>
>hope this helps.
>regards, toby
>
>--
>-----------------------------------------< tobias.bocanegra@day.com >---
>Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
>T +41 61 226 98 98, F +41 61 226 98 97
>-----------------------------------------------< http://www.day.com >---

_________________________________________________________________
Tried the new MSN Messenger? It’s cool! Download now. 
http://messenger.msn.com/Download/Default.aspx?mkt=en-in


Re: Questions about versioning

Posted by Tobias Bocanegra <to...@day.com>.
hi paco,
please note, that versioning has nothing to do with locking.

> - If the user A performs a Checkout, why can user B modify and checkin?
becauses it's not locking....

> - Do the A user have to lock himself the node?
yes.

> - If the user B can modify and perform a checkin, what happends if
> meanwhile user A modify the node? In my test, the last modification
> (user A) is versioned, and the user B modification (performed before
> user A modification) is lost. Is this ok?
yes.

> So, if all these is fine I have to do something like this:
>
> -> User A lock node
> -> User A performs checkout
> -> User A modify node
> -> User A performs checkin
> -> User A unlock node
>
> isn't it?
correct.

if you don't want to use locking, you can create several workspaces
for you users. for example workspace A for user A, and workspace B for
user B:

- User A logs into workspace A
- User B logs into workspace B
- A does a checkout of Node N
- B does a checkout of Node N
- A modifies N and does checkin -> version 1.1
- B modifies N and does checkin -> version 1.0.1 (new branch, since
1.1 already exists)

hope this helps.
regards, toby

-- 
-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---