hi dave

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.

as far as i know that is the default behaviour defined in JSR 170 if a
node is made mix:versionable.
see section "8.2.4 Initializing the Version History".

if this turns out to be a problem with dav clients, we should add
the line you suggest.

the only drawback of the additional checkin would be, that this
creates an extra version in the repository without necessitiy (and without having made any changes).

so: it doesn't "create a new version resource in that v-history"
but two of them: the root version and the subsequent v1. this
doesn't look inituitive to me...

but i don't have any strong feelings about the change, if the
current behaviour turns out to be problematic. in this case you
may open an issue in jira.

thanks & regards
angela



Reply via email to