Dave Fried wrote:
The WebDAV standard seems to indicate that the result of a VERSION-CONTROL
request should be a resource which is in the checked-in state:
"If the request-URL identified a
versionable resource at the time of the request, the request MUST
have created a new version history and MUST have created a new
version resource in that version history. The resource MUST have
a DAV:checked-in property that identifies the new version."
But Jackrabbit's WebDAV implementation seems to leave the resource in the
checked-out state. This probably isn't a problem in most cases, since the
VERSION-CONTROL request, when applied to an already version-controlled
resource, is not guaranteed to leave the resource in a checked-in state, so
applications will have to handle this anyway. But it seems like an
arbitrary departure from the standard.
Two questions:
* is this ever a problem in practice? (in other words, should I care?)
I can imagine it can be a problem that rely on the semantics.
* is there an easy way to add the version-controlled JCR mixin to the
resource and check it in atomically, all in one fell swoop, as part of the
version-control handler?
For example, in VersionControlledResourceImpl::addVersionControl(), would
the following code work?
if (!isVersionControlled()) {
Node item = getNode();
try {
item.addMixin(JcrConstants.MIX_VERSIONABLE);
item.save();
item.checkin(); // <<<====== ADDED LINE OF CODE
} catch (RepositoryException e) {
throw new JcrDavException(e);
}
}
Should checkin() come before save()? I am not so familiar with how JCR
works yet.
I think moving it up wouldn't work, as the addMixin request wouldn't
have been executed yet.
BR, Julian
