Next message: Geoffrey M. Clemm: "Workspace/Target-Selector vs. Target-Selector/Request-Target-Selector"
Date: Sat, 29 Apr 2000 13:14:05 -0400 (EDT)
Message-Id: <200004291714.NAA08090@tantalum.atria.com>
From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com>
To: ietf-dav-versioning@w3.org
Subject: Re: new "Advanced Versioning Semantics" section
From: jamsden@us.ibm.com
It wasn't clear how the SET-TARGET method populated the workspace with
revisions. Maybe just another sentence there would help.
It occurs to me that although SET-TARGET and MERGE are equivalent
on an empty workspace, it would probably be better to say that the
MERGE method is the standard mechanism for initializing a workspace,
since a workspace is commonly initialized from a baseline, and using
a MERGE would mean that this baseline would be tracked in the
DAV:predecessor-set of the workspace.
The primary use of SET-TARGET on a workspace would be to "jump back"
to a previous revision or to a different branch, which is a much less
common scenario. Adding some words to this effect would probably be
worthwhile as well.
If core versioning uses a default revision on a versioned resource,
wouldn't using a default workspace be in conflict with this?
On an advanced versioning server, a request to set the default target
is really a request to set the target of the default workspace
(but a core client doesn't have to know that).
Wouldn't there
be two defaults specified? Or are these merged by setting the default
version of a versioned resource to a workspace rather than a label? If so,
this should be pointed out so one can see how default workspaces don't
introduce a new paradigm.
I agree. I'll try to add a sentence or two to make this clear.
It also wasn't clear how one would use different
default workspaces on different resources, but noting that they are just a
revision selector just like a label might clear up this confusion.
Will do. There is only one default workspace for a URL, but you can
override this with a Target-Selector header.
I particularly liked the sections on merging and activities. Indicating
merge conflicts arise when neither revision is a predecessor of the other
is the simplest way I've ever heard this described.
Thanks!
Cheers,
Geoff