W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > January to March 2002


From: Konstantin Knizhnik <KKnizhnik@togetherlab.com>
Date: Thu, 10 Jan 2002 21:08:55 +0300
Message-ID: <1684970967.20020110210855@togetherlab.com>
To: ietf-dav-versioning@w3.org
If server doesn't support workspaces (or server supports workspaces but
client is not using this feature), is there any chance to get
version controlled resource for the given version or version history?
Suppose the following scenario:

MKDIR MyProject
PUT MyProject/foo.txt

So now version controlled resource, version history and initial version
are created for all resources in MyProject.

Now I set the label to the project:

LABEL MyProject
Depth: Infinite
<DAV:label xmlns:DAV="DAV:">

Later I want to extract this state of the project. Certainly I know
that BASELINE is write way for doing it, but
1. What if server doesn't support baselines (labels belong to the
basic versioning stuff, while baselines belong to advanced)?
2. Once labels are defined by specification, it should be clear how to
use them, right?

So I do:

depth: Infinite
<DAV:propfind xmlns:DAV="DAV:">

So I will be given information about all versions in MyProject labeled
by "ALHPA-RELEASE". Is is ok, but now I want to extract this files to
the client's local disk. In here is a trouble - I don't know path of
the resources. In report I will be given:


How the client will understand that foo.txt should be saved in the
file \MyProject\foo.txt at local disk?
The only way is to find out version controlled resource for the givven
version (or version history).
Report locate-by-history requires workspace as request target. But
client knows nothing about workspaces and my be that are not even
supported by server.
So what should I do?

If version history will be specified as target of LOCATE-BY-HISTORY report
and workspace can be optionally specified in request body, then
this report can be used to get versioned resource even if server
doesn't support workspaces or it support workspaces and when workspace
is not explicitly specified by client, then resource is implicitly
placed in some default workspace.
But even in this case getting resource name require two additional
requests: PROPFIND to get version history by version and
locate-by-history REPORT to give versioned resource reference.

Another way is to add property <DAV:defaultdisplacepath/> with the
following semantic:
- for version controlled resource, it returns its URL
- for version and version history - URL of version controlled resource
  in default workspace if such exists
Received on Thursday, 10 January 2002 13:05:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:55:48 UTC