FWD: [Geoffrey Clemm] Re: WeDAV Versioning Summary
Ralph R. Swick (swick@w3.org)
Mon, 24 May 1999 09:08:23 -0400
Message-Id: <3.0.5.32.19990524090823.02b52310@127.0.0.1>
Date: Mon, 24 May 1999 09:08:23 -0400
To: ietf-dav-versioning@w3.org
From: "Ralph R. Swick" <swick@w3.org>
Subject: FWD: [Geoffrey Clemm] Re: WeDAV Versioning Summary
>Date: Fri, 21 May 1999 22:50:12 -0400 (EDT)
>X-Sender: gclemmw@tantalum.atria.com (Unverified)
>Old-Date: Fri, 21 May 1999 19:52:50 -0400
>To: ietf-dav-versioning@w3.org
>From: Geoffrey Clemm <geoffrey.clemm@rational.com>
>X-Diagnostic: Not on the accept list
>Subject: [Moderator Action] Re: WeDAV Versioning Summary
>
>Very nice summary, Jim!
>
>A few minor nits:
>
>At 07:03 PM 5/20/99 -0400, jamsden@us.ibm.com wrote:
>>... There is a distinguished
>>revision selector called "latest" which always refers to the latest revision
>>based on last modified time.
>
>That should be "revision creation time".
>
>>A revision of a collection is modified by adding or removing member URLs.
>
>With the new advanced collection "binding" semantics, this would be phrased:
>
>A revision of a collection is modified by adding or removing bindings to
>versioned-resources.
>
>> An activity matches the latest revision in that activity, and
>>may result in merge conflicts with changes made in other activities.
>
>Merge conflicts occur through the use of the "DAV:rsr-merge" rule. An
>activity
>can be a sub-element of a merge rule, but so can any other version selection
>element such as a configuration or a label.
>
>> Latest matches
>>the latest revision based on the last modified time.
>
>Based on the revision creation time.
>
>> A revision
>
>>that is already checked out in an activity cannot be checked out again in
>the
>>same activity.
>
>You might want to say "currently checked out" instead of "already checked
>out".
>Otherwise it might give people the wrong impression that you can only have one
>revision of a versioned-resource in an activity (you can have as many as
>you want,
>but you can only have one checked out at any one time).
>
>>The workspace merge conflict report is not available to detect conflicts
>>resulting from changes that were not made in the context of an activity.
>Client
>>applications are responsible for detecting and integrating the changes.
>
>The conflict report should work just as well with label-based conflicts as it
>does with activity-based conflicts. Probably should just delete these two
>sentences.
>
>> Two workspaces with different current
>>labels can work in parallel on the same versioned-resource, and then
>simplified
>>merging can be performed by adding both labels to the revision selection
>rule of
>>the workspace incorporating the changes done in other workspaces.
>
>These two labels would be two sub-elements of a DAV:rsr-merge element, just
>as two activities would be if you wanted to merge them. So the merging is no
>easier or harder with labels vs. activities.
>
>>A versioned collection has an associated baseline which is a distinguished,
>>versioned configuration containing the collection, and recursively, all its
>>members. A new revision of a versioned collection baseline is created by
>>baselining the collection.
>
>This should be slightly modified to read:
>
>A versioned collection can have an associated versioned configuration,
>where each revision of the versioned configuration contains a revision of
>the collection, and recursively, a revision of each of its members.
>A new revision (called a "baseline") of this versioned configuration is
>created by
>"baselining" the associated versioned collection.
>
>>As described in the section "Configurations", a versioned collection may
>have a
>>baseline which is a versioned configuration selecting a revision of the
>
>>versioned collection, and recursively revisions of all its members.
>
>"... a versioned collection may have an associated versioned configuration,
>where
>each revision of the versioned configuration is called a "baseline" of the
>versioned-
>collection. Each baseline selects a revision of the versioned-collection,
>and recursively
>revisions of each of its members."
>
>>Locking a versioned resource prevents any revision from being checked out
>in any
>>activity.
>
>Jim and I are currently discussing this. I believe that for downlevel
>client access,
>locking a versioned resource should mean locking the revision or working
>resource
>currently selected by that versioned resource. This means that we would
>use some
>other means to prevent checkouts.
>
> >Locking a revision of a versioned resource prevents just that revision
>>from being checked out in any activity.
>
>Since downlevel clients will be issuing locks on versioned resources, which
>I believe should be applied to the revision selected by that
>versioned resource, then I think it's important to just have LOCK prevent
>changes
>to the resource, and not have additional semantics such as preventing
>checkouts.
>
>And thanks again to Jim for all his hard work in putting together this
>summary!
>
>Cheers,
>Geoff