jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ChadDavis <chadmichaelda...@gmail.com>
Subject version control basics
Date Mon, 01 Nov 2010 21:31:22 GMT
The specification says that checked-out means that "The checked-out
state indicates to the repository and other clients that the latest
version of N is 'being worked on' and will typically be checked-in
again at some point in the future, thus creating a new version."

This language seems to suggest that the semantics of the API are a
perfect match for common sense use cases of a version control
supporting CMS.  But I can't quite get it to work out . . .

Edit Document:

1) checkout  ( now, the document is checkedOut; in other words, other
users can't edit )
2) make changes
3) checkin ( now, the document is open to edit by other users with the
proper permissions )

In this context, the language from the spec makes sense.  Note,
however, that this model requires a new version be added to the
history for EVERY edit session.  I don't think it makes sense to
create an official version of the document for each editing session,
but the only way I can move the document back to the "checked in"
state, is to use the checkin method that creates a new version.  This
means that either I give up on the semantics of using "checked out" as
a way of informing other users that they aren't allowed to edit the
document because "it's being worked on", or i accept the creation of
an official version each time I have an edit session.

I've read on this list, that some developers keep the document always
in the checkedOut state and only move to the checked in state when
committing an official version of the document.  After which they
immediately checkOut the document again.  This works for me, but seems
to be a waste of the entire concept of "checked out".

Can someone please provide insight into the proper use of this API?

Mime
View raw message