W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > October to December 2001

Re: [daniel.kirmse@sap.com: WebDAV/DeltaV: GET on Version Tree]

From: Alan Kent <ajk@mds.rmit.edu.au>
Date: Tue, 11 Dec 2001 10:38:46 +1100
To: ietf-dav-versioning@w3.org, daniel.kirmse@sap.com
Message-ID: <20011211103845.A7852@io.mds.rmit.edu.au>
On Mon, Dec 10, 2001 at 04:29:49AM -0800, Greg Stein wrote:
> This question is best directed to the DeltaV group for answering...

Wow, Greg did not instantly answer himself! Greg must be slipping! :-)
(I remember well the many instant and informed responses Greg replied
with when I started asking questions.)

> I've a few problems not handled in the WebDAV-FAQ of webdav.org:
> 1.Suppose you have a resource A.file with a version tree as follows:
>            A.file,1
>               |
>            A.file,2
>               /\
>              /  \
>             /    \
>            /      \
>     A.file,2.1   A.file,2.2
>          |              |
>    A.file,2.1.1  A.file,2.2.1
> where the version number does not necessarily express the sequence of
> creation of the versions. All versions are checked in.
> Suppose a client sends a GET A.file Request. Which version of A.file must be
> sent as response, A.file,2.1.1 or A.file,2.2.1?

My understanding is you do not do a GET on A.file. You do a GET on
a URL. The URL must be bound to a particular version by the server.
So you get whatever version the URL has been bound to. There are DeltaV
commands for changing the version a URL is bound to.

> 2.I'd like to use server workspace for emulating a development (DEV) and a
> consolidation (CONS) source tree of a single source tree. 
> Suppose I have a source tree. 
> 		"/" (root)
> 		/
> 	     src
>            / \
>           /   \
>          a.c  b.c
> Where a.c and b.c are version-controlled resources. In the beginning of my
> development I create a workspace DEV to contain all resources of a certain
> development.
> 		"/" (root)
> 		/        \
>            /          \
>           src         DEV
>           / \          |
>          /   \         |
>         a.c  b.c      src
>                       / \
>                      /   \
>                    a.c  b.c
> Files a.c and b.c are part of the worksapce and after some time there are
> version 4 of a.c and version 3 of b.c are candidates for delivery. So I set
> up a new workspace emulating my consolidation source tree (CONS) as a copy
> of the DEV workspace, copying the latest version of a.c and b.c to it. (Is
> it allowed so far?)

Sounds OK to me...

> In my oppinion now a checkin of a.c in DEV and in CONS
> would produce a branch in the source tree of a.c (right?).

I think that is partially up to the implementation as to what the DetaV
server did. But it would be reasonable behaviour.

> Now suppose a user with a user worksapce /usr/dan who has to fix a bug in
> a.c both in DEV and CONS. I think it is not allowed to have to versons of
> a.c in the same workspace (right?), so user dan has to set up two workspace
> to get this done (right?). 

I think that is correct - or use the UPDATE command (I think it is
from memory) to change the version a URL points at. But creating two
workspaces seems reasonable.

> Finally the question is: Is it possible for user dan to copy /DEV/a.c into
> his workspace or MUST he copy /src/a.c into his workspace? Or the other way
> around: Is it possible to have a workspace as a source of resources for
> another workspace?

You can certainly do a copy from one workspace to another.
There is no requirement for /src/a.c and /src/b.c to exist.
In our planned DeltaV implementation (ok, so its been planned
for a while now! :-) we would not have /src/a.c ever existing.
We plan to start with users creating workspaces and then adding
files under there. Each user will get a home directory to use,
and then we will let them create whatever directory structure
they like under that, including workspaces. The structure under
the workspace will then be version controlled (and so be the same
between users - unless users change the directory structure
(which is also versioned)).

I hope the above helps (and is correct :-).

Received on Monday, 10 December 2001 18:39:22 UTC

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