RE: Adding a new file to an activity

   From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com]

   O.k. after some more reading and thinkinh I'll take version-controlled
   collections. But there are some questions left:

   0. Does a checkout to a version-controlled collection always create a
   working-collection? So there is no checkout-in-place available for
   version-controlled collections.

A version-controlled collection is just a VCR with some additional
rules, so it inherits all the VCR rules.  In particular, this means
that when you apply CHECKOUT to a VCR, it is an in place checkout
unless you specify the DAV:apply-to-version parameter.

   1. Do I understand it the right way if I assume in order to have a
"hidden"
   PUT (adding a new file w/o makinging it visible within the workspace
   (codeline) containing all the VCR's) I have to perform an explicit
checkout
   to the version-controlled collection that's to contain this file.

Yes.

   After that
   I perform the PUT on the working collection.

Yes.

   And not before checkin there is
   the newly added file visible in the workspace.

Yes.

   By the way a new baseline of
   the baseline-controlled workspace is created (because of the change of
the
   DAV:checked-in property of the version-controlled collection)?

Yes, if you have DAV:auto-version appropriately set on the
DAV:version-controlled-configuration of the workspace
(e.g. DAV:checkout-checkin).

   2. Every namespace operation (DELETE, MOVE, COPY) and only they (except
for
   MKCOL see 5.) would cause an auto-checkout if auto-version is set to
   DAV:checkout behavior?

Auto-checkout only occurs for in-place checkouts (there is
no way to specify a DAV:apply-to-version flag for an auto-checkout).
Auto-checkout is primarily for versioning unaware clients,
and this means that the result of auto-checkout must be something
that makes sense to a versioning unaware client (and leaving the
resource unchanged while returning a working collection containing
the change is *definitely* not something that would make sense
to a versioning unaware client).

   3. In case 2. is true: Is there a way to give an activity the
   created working-collection will be bound to? Maybe I just give the
   DAV:activity-set tag in the body?

This only applies to "in-place" checkouts, but currently the
only interoperable way of setting the activity for auto-checkout
is through the DAV:current-activity-set of the workspace.
If your client wants greater control on the activity, it either
needs to do explicit CHECKOUT's, or needs to adjust the DAV:activity
value once the auto-checkout has occurred.

   4. A non-version-controlled resource MUST be created within the
   version-controlled collection itself instead of creating it within
   the working collection?

Yes.  All non-version-controlled members of a working collection
are put under version control when that working collection is
checked in.

   5. As I come to think of it: MKCOL will not cause an
   working-collection to be created when performed on a
   version-controlled collection, will it?  Because at MKCOL it is not
   clear wether the created collection will be under version-control
   (if no auto-version-control behavior is implemented). Or more
   precise: MKCOL creates non-version-controlled collections (if no
   auto-version-control behavior is implemented)?

Correct.

   6. What about Request that deal with two version-controlled
   collections as for example MOVE. With an auto-version =
   DAV:checkout both collections have to be checked out, two working
   collections are created. The source collection working-collection
   will get rid of the binding of the moved out resource. The
   destination collection working-collection will add a new binding
   for the moved in resource. But now I'm free to check in the source
   collection working-collection, so the binding there is gone with
   the wind.  And I delete the destination collection
   working-collection, so the new binding is not added. The result is
   inconsistent, its a half way done MOVE!  Is there anything to
   prevent this?

Note that auto-versioning does not occur with working resources.
But your question is still valid, when applied to explicitly
created working collections (all working collections must be
explicitly created by CHECKOUT).

A "partial-MOVE" is the same as a DELETE.  If that what a client tells
the server to do, the server must do it.  Similarly, there is no way
for a server to tell when a client issues a DELETE when it meant to
issue a MOVE.  If a client has a bug and sends the wrong requests
to the server, there's not much a server can do about it.

Cheers,
Geoff

Received on Wednesday, 16 January 2002 09:47:04 UTC