RE: Adding a new file to an activity

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.

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

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?

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?

4. A non-version-controlled resource MUST be created within the
version-controlled collection itself instead of creating it within 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)?

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?

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

Regards,
Daniel



>-----Original Message-----
>From: Clemm, Geoff [mailto:gclemm@rational.com]
>Sent: Dienstag, 15. Januar 2002 14:46
>To: Ietf-Dav-Versioning (E-mail)
>Subject: RE: Adding a new file to an activity
>
>
>   From: Kirmse, Daniel [mailto:daniel.kirmse@sap.com]
>
>   suppose I have a repository landscape with a workspace under
>   baseline-control. The workspace contains my VCR's. 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.
>
>   Well what if a client wants to add a file to the repository using a
>   given activity (or a newly created one). The file should be placed
>   under version control automatically. Do it have to directly add the
>   file/resource to the workspace where all the VCR's are stored?
>
>Yes.
>
>   Or is there a way to have a working resource connected to the
>   activity and creating the VCR of that file at checkin?
>
>To keep that resource "hidden", your server would need to support
>either multiple workspaces or version-controlled collections.
>With multiple workspaces, you could create the new resource in
>a second workspace, and it would be hidden until you MERGE'd
>into the first workspace.  With version-controlled collections,
>you could checkout the collection that is to contain the new
>resource, add the resource to the working collection, and the
>new resource will only be visible when you check in that working
>collection. 
>
>>>>> snipp
>

Received on Wednesday, 16 January 2002 06:49:36 UTC