Date: Sun, 21 May 2000 00:04:04 -0400 (EDT) Message-Id: <200005210404.AAA09292@tantalum.atria.com> From: "Geoffrey M. Clemm" <geoffrey.clemm@rational.com> To: ietf-dav-versioning@w3.org Subject: Re: Three questions From: Dan Kegel <dank@alumni.caltech.edu> It is handy, for instance, to export an entire Perforce tree via https. That way, plain old web browsers can use absolute URLs to refer to file foo.c in branch 1.2 of collection foo as https://hostname/prefix/foo/1.2/bar.c and to file foo in the mainline (i.e. the as-yet-unbranched) collection foo as https://hostname/prefix/foo/mainline/bar.c With WebDAV, the "branching" would be done at the workspace level, not at each collection level, so that relative references continue to work. So assuming you have a "main" workspace and a "1.2" workspace, the two files would be referred to as: https://hostname/prefix/1.2/foo/bar.c and https://hostname/prefix/mainline/foo/bar.c This way, relative references in bar.c such as "../include/foo.h" would continue to work in either workspace (but would not work if you introduced branch names as intervening directories). > I have therefore added this to the "issue list" (it appeared on the > agenda for this weeks phone call). In particular, I propose that > a workspace resource be modelled as a collection resource, and that > the "contents" of a workspace can appear as members of that workspace. Can you illustrate how one might export a version tree via plain old http with your proposal (since I don't quite grok delta-v lingo yet)? You use the DAV:revisions property to give you the stable URL's for each revision, or you can use the DAV:property-report to give you information about all these revisions in a single request (see the DAV:property-report example for details). OK. I should put together a list of the Perforce operations I'd like to map, and the delta-v they map to. Let me know about any operations that you have trouble mapping. Cheers, Geoff