Next message: Geoffrey M. Clemm: "Re: Initializing a new workspace using an RSR"
Date: Thu, 20 Apr 2000 22:47:37 -0400 (EDT)
Message-Id: <200004210247.WAA25062@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: Initializing a new workspace using an RSR
From: Henry Harbury <Henry.Harbury@merant.com>
Assuming static workspace behavior (draft 4.2), I think it would be
useful to use the old concept of an RSR to (optionally) initially
populate a new workspace when created. The RSR could be passed in
the header of a MKWORKSPACE method. The workspace would then be
populated using this RSR, and the RSR could then persist as a
protected property of the workspace for later use/reference.
There are two issues here:
- Should you be able to populate a workspace as part of the MKWORKSPACE
method.
- Should the things that populate a workspace be tracked (by an RSR or
some equivalent mechanism).
The workspace would then follow the "static" behavior
for revision selection (using the SET-DEFAULT-REVISION method associated
with that workspace). This would greatly simplify the use-case for
creating workspaces on-the-fly based on labels/activities/baselines/etc.
Why is it simpler to initialize the workspace in the MKWORKSPACE request,
rather than populating it in a subsequent MERGE or SET-DEFAULT request?
It saves one round trip, but that probably is not a significant cost.
It might be useful to define a difference report of the current
selection of a static workspace and what the originating RSR would
select at the time of the report.
I agree that tracking the baselines that have been merged into the
workspace is important (they are the "predecessors" of a new baseline
created from that workspace), and that tracking the activities and
other workspaces that should periodically be merged into the workspace
is also important (I'd probably separate them out DAV:merge-workspaces
and DAV:merge-activities).
This would give the client a way to
"remember" what that particular workspace was intended for (based on its
initialization RSR), and what is currently different between that RSR
and that active workspace's selection.
Yes, I agree that a DAV:compare-report could then be used to see how the
workspace differs from its predecessor baselines.
Cheers,
Geoff