Angela Schreiber wrote:
...
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).
...
I would call that an advantage :-)
After all, if you don't want the current state of the resource to become
the first version, then you can do the edits first and then invoke
VERSION-CONTROL.
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...
Well, it's what the spec requires. And yes, it's unfortunate that
RFC3253 and JSR170 -- given the same author for this part :-) -- require
opposite behaviours.
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.
I'd be in favor to change it without an actual bug report. Problems like
these can be hard to debug.
What we need is a WebDAV test case...
BR, Julian
