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?
