RE: Adding a new file to an activity

"Kirmse, Daniel" <daniel.kirmse@sap.com> wrote:

> Landscape:
> >   suppose I have a repository landscape with a workspace under
> >   baseline-control. The workspace contains my VCR's and 
version-controlled
> collections. Checkout is done
> >   with DAV:apply-to-version and DAV:activity-set (href or new). So
> >   Work in process is represented by working-resources collected in
> >   activities. Baselining is done with auto-version = checkout-checkin.
> 
> 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.

No, you can have a checked-out version-controlled collection (i.e., 
checkout in place).

> 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. After 
that
> I perform the PUT on the working collection. And not before checkin 
there is
> the newly added file visible in the workspace.

Yes, to keep the new resource hidden from other users of the same 
workspace, you would have to create a working collection (possibly with 
the auto-update feature so that it is reflected back in the workspace when 
the working collection is checked in).

> 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)?

The new auto baseline would be created when the working collection is 
checked-in (assuming auto-update).  As you point out, it occurs when the 
DAV:checked-in property of any version-controlled resource changes.

> 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?

Yes,  I was thinking about MERGE too, but that does it's 'own' check-outs 
so does not rely on auto-versioning behavior.

> 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?

No, it is not defined for those namespace modifying operations to take an 
DAV:activity-set tag in the body, so you would have to rely upon the 
DAV:current-activity-set of the workspace to capture them.
 
> 4. A non-version-controlled resource MUST be created within the
> version-controlled collection itself instead of creating it within the
> working collection?

If you want the resource to remain non-version-controlled, then yes.  It 
is defined that checking in a working collection applys VERSION-CONTROL to 
all the versionable resources in the working collection.

> 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)?

although the new collection will not be version-controlled, the parent of 
the new collection will have been modified to add the new internal member 
name, so it much be checked-out (automatically or otherwise).  Inthis 
respect, there is no difference between a MKCOL and a PUT, DELETE, etc.
 
> 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.

Since you are applying MOVE to members of two version-controlled 
collections, then the auto-versioning will checkout the version-controlled 
collections in-place.  This would not create any working collections.

> 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?

No, if you apply the MOVE to working collections so that they are 'work in 
progress' there is nothing to prevent clients from checking in one working 
resource and DELETEing the other.  Although the MOVE was good, the 
checked-in results would be inconsistent (either the binding disappears 
alltogether, or there are now two bindings to the same history depending 
upon which you checked in and which you deleted).

> So that's all for now, maybe there are some more questions to come later 
on.

I'll add my usual plug for the DeltaV FAQ.  It would be good if you could 
add any "aha!'s" to the FAQ at http://www.webdav.org/deltav/faq

Regards,
Tim

Received on Wednesday, 16 January 2002 09:27:14 UTC