Hello Anton,
> At this stage we are looking at utilizing the client's webdavResource
> class in particular. I have found some 'features' :) of the command-
> line client. (which I use as a reference for my app)
> - checkout,checkin and uncheckout are listed as commands in
> the help, but
> return "invalid command" if you try them.
> - report is shown in the help as having an optional 3rd parameter, but
> the command gives a syntax error if you leave out the 3rd argument.
> - "help /?" exits the command line
As Juergen Pill pointed out, not all of the DeltaV methods are done in Slide
client.
> Regarding versioning, I see that with auto-versioning on,
> when a property
> is changed for a given path, a new version is created - not
> quite what I
> expected, but logical I suppose - treating the file and it's
> properties as
> a unit.
Well, with respect to auto-versioning, RFC 3253 states:
"The DAV:auto-version property (see Sections 3.2.2) of a checked-in
version-controlled resource determines how it responds to a method that
attempts to modify its content or dead properties."
In Domain.xml, the parameter "auto-version" (at end of the file) specifies
the default value for the DAV:auto-version property. If it is
"checkout-checkin", each operation which changes the state of the resource
(PUT, PROPPATCH, COPY) implicitly creates a new version. For clients which
are versioning-unaware but support locking, one of the other three values
("checkout-unlocked-checkin", "checkout", "locked-checkout") may be more
suitable as the creation of new versions can be combined with the locking
mechanism, e.g. by creating a new version only when the resource is
unlocked.
> My earlier tests with lock/unlock showed the locking
> to be rather
> short lived (2 mins in my test) -
The "Timeout:" header of the LOCK request should help to control how long
the lock lives. A value of "Infinity" is possible.
> I'm looking to implement an
> exclusive
> check-out, and had considered using properties to handle it (set
> editor=whomever to lock and set editor="" to unlock with check-in.
> any suggestions / pointers ?
One way to obtain exclusive check-out would be by forbidding branching ...
if that is acceptable. To forbid branching, the DAV:checkout-fork and
DAV:checkin-fork properties should be set to "forbidden". Again, defaults
can be specified using the corresponding parameters at the end of the
Domain.xml file. Otherwise, maybe combining check-out with exclusive locks?
I would try to anyhow let the DeltaV server do it instead of using my own
"controlling" properties.
Regards,
Peter
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
