On 7/30/08, Paco Avila <[EMAIL PROTECTED]> wrote: > Yes, in my application we perform a checkout and lock the node to prevent > modifications from other users (an "exclusive checkout" ). > > The problem is when I put a document in the repository its version is named > "jcr:rootVersion" until I perform a checkin. After that, version name > becomes "1.0". When I put a document in the repository it means to be the > first version, an the first version is supposed to be "1.0". > > The second issue is about versioning procedure. If I work with versioned > nodes, the procedure is: > > - CheckOut (now the document is editable) > - Modify the document > - CheckIn (Version number is incremented and the document is not editable) > > Isn't it? What happend the first time (when just I have uploaded the > document)? The document is in checkout state, so I don't need to perform > this operation. The next time I have to because it is checkedin. Why the > first time have to be different? ah, your talking about uploading a document via webdav? in this case you could alter the webdav servlet to do an automatic checkin after creating the nodes.
regards, toby > On Tue, Jul 29, 2008 at 5:15 PM, Angela Schreiber <[EMAIL PROTECTED]> wrote: > > > hi paco > > > > not sure, whether i understood, what you are trying to do. > > if you want to make sure that only a single user can > > create/modify a given node and create new versions > > of it, you should in addition to the versioning functionality > > make usage of locking. > > > > a checked-in node is prevented from being modified. but > > it is not locked... so everybody (with the proper privileges) > > will be able to checkout and consequently modify the > > node. similarly a checkout-node that is not locked by a > > Lock on itself (or by a deep Lock inherited from a parent) > > can be modified by any user that is allowed to modify that > > node. > > > > hope that helps. > > angela > > > > > > > > > > > > The problem is that when I put a document in the repository, this document > >> should be available for user modifications. If another user should no > >> update > >> the document because he have to perform a checkout-modification-checkin > >> procedure. > >> > >> On Tue, Jul 29, 2008 at 2:38 PM, Tobias Bocanegra > >> <[EMAIL PROTECTED]>wrote: > >> > >> On 7/28/08, Paco Avila <[EMAIL PROTECTED]> wrote: > >>> > >>>> In my application, a document node is uploaded to the repository and > >>>> cheked-in. Then it is versions as 1.0 and any other user can edit it > >>>> performing a previous check-out. The document node also is locked to > >>>> preserve it from modifications by other users. > >>>> > >>> and what is the problem right now? > >>> regards, toby > >>> > >>> On Mon, Jul 28, 2008 at 9:25 PM, Tobias Bocanegra > >>>> <[EMAIL PROTECTED]>wrote: > >>>> > >>>> > >>>> > hi, > >>>> > the initial state of a versionable node is checked-out with a base > >>>> > version to the root version. the point is, that you cannot edit the > >>>> > node, unless it's checked out. so in your world, the node would be > >>>> > transiently checkedout until you save it, and the automagically > >>>> become > >>>> > checked-in? i don't think so. > >>>> > > >>>> > regards, toby > >>>> > > >>>> > On 7/28/08, Paco Avila <[EMAIL PROTECTED]> wrote: > >>>> > > This is an old issue, but now I wonder why when I add a node, its > >>>> > checkedOut > >>>> > > property is set to true. Does it make sense? I think it should be > >>>> > >>> in > >>> > >>>> > > checked-in state. > >>>> > > > >>>> > > >>>> > >>>> > >> > > >
