Next message: jamsden@us.ibm.com: "Re: Initializing a new workspace using an RSR"
Date: Wed, 26 Apr 2000 00:08:54 -0400 (EDT)
Message-Id: <200004260408.AAA02618@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: new "Advanced Versioning Semantics" section
OK, here's a stab at improving the advanced versioning semantics
section. Please let me know if this is in fact an improvement. I've
uploaded a new working draft (4.3) of the protocol to
http://www.webdav.org/deltav site if you'd like to see this section in
context.
Cheers,
Geoff
8 ADVANCED VERSIONING SEMANTICS
8.1 Target Selection and Workspaces
Core versioning provides a label as a target selector that can be
used to select a consistent set of revisions, but provides no
mechanism for selecting a consistent set of working resources. In
addition, core versioning provides no mechanism for a client to
determine whether a given label is already in use for some other
purpose. In order to address these issues, advanced versioning
introduces the concept of a "workspace" resource.
A workspace URL can be used wherever a label or working resource id
can appear. Unlike a label, a new workspace is registered with a
MKWORKSPACE request, thus ensuring that a client will not
mistakenly use a target selector already in use by another client.
Unlike a working resource id, which is allocated by the server for
a single versioned resource, a workspace can be used by a client to
identify multiple working resources. This significantly simplifies
a client implementation by allowing the use of a single URL to
identify a consistent set of revisions and working resources.
A workspace is initially populated with SET-TARGET requests that
cause it to select a particular set of revisions. A CHECKOUT
request that specifies that workspace in a Target-Selector header
creates a new working resource identified by that workspace. A
subsequent CHECKIN request creates a new revision that is selected
by the workspace.
If no workspace is specified for a request, a server determined
"default workspace" is used. This is the workspace used by all
versioning-unaware clients. A server can associate different
default workspaces with different URL's, and thereby expose
multiple workspaces to versioning unaware clients.
When a lock is applied to a versioned resource, the namespace
locking implied by that lock (i.e. the inability to MOVE or DELETE
that resource) holds only in the workspace specified for the lock
request. When no workspace is explicitly specified by the lock
request, the namespace locking applies to the default workspace.
8.2 Baselines
A workspace selects a volatile set of revisions. When a workspace
is placed under version control, workspace revisions called
baselines can be created to capture the set of revisions selected
by the workspace at a particular moment. This can be useful for a
variety of purposes such as publishing consistent revisions of
resources to deploy an application, or for recovering a specific
state for legal or maintenance reasons.
8.3 Parallel Development and Merging
When all clients are using the same workspace, a change made by one
client is immediately visible to all other clients. In situations
where the work of one client would be disrupted by changes made by
other clients, it is desirable to allocate a separate workspace for
that client. When that client is ready to see changes made by
clients in another workspace, it can "merge" that other workspace
into its workspace. Since the revisions selected by a workspace
could change in the middle of the merge operation, it is common to
merge a baseline created by that other workspace, rather than just
the revisions currently selected by that other workspace.
In case the other workspace selects a revision of a versioned
resource that is on a different line of descent than the one
selected by the workspace (neither revision is an ancestor of the
other), the contents of those revisions must be merged. For each
versioned resource with such a conflict, the merge request will
create a new working resource with the appropriate revisions as the
predecessors. The client is responsible for modifying the contents
of the working resource so that it represents the logical merge of
the two revisions, and then checking in the working resource.
Normally, the "merge state" of a working resource created by a
merge request is "initial", indicating that the contents of the
working resource is just a copy of the revision originally selected
by the workspace. In case the server is capable of performing part
of the merge automatically, it indicates that it has done so by
setting the merge state of the working resource to be
"intermediate". If the server believes it has correctly merged the
revisions, it indicates that it has done so by setting the merge
state to be "final". Even if the merge state is final, it is still
the responsibility of the client to verify that the merge is
correct, and then to checkin the working resource.
Another reason a client may choose to use a separate workspace is
to allow concurrent modification of the same versioned resource.
Each workspace has its own working resource for that versioned
resource, and the merge operation ensures that these concurrent
changes will be merged instead of one overwriting the other.
8.4 Activities
In some advanced versioning scenarios, several different logical
changes are performed in a single workspace, but another workspace
only wants a subset of those changes. An "activity" resource
provides the mechanism for addressing this problem. Each activity
represents a single logical change, although many resources might
need to be modified to effect that single logical change. When a
working resource is created, the client specifies which activity
that working resource will contribute towards. When a working
resource is checked in to create a new revision, the association
between the working resource and an activity is inherited by the
newly created revision. The results of an activity can then be
merged into another workspace with a MERGE request.
Another use for an activity is to avoid merges. Since only one
working resource of a versioned resource can be checked out in the
context of a given activity, two clients can avoid merging with
each other by selecting the same activity as the current activity
of their workspaces. If one client attempts to check out a
versioned resource already checked out by the other client, the
checkout request will fail. The client would then have to either
checkout the versioned resource in a different activity, or wait
until the other client checked in its working resource for that
versioned resource.