jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julian Reschke <julian.resc...@gmx.de>
Subject Re: Result of VERSION-CONTROL request
Date Wed, 29 Oct 2008 17:06:39 GMT
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

Mime
View raw message