- From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
- Date: Thu, 21 Dec 2000 11:32:32 -0500 (EST)
- To: ietf-dav-versioning@w3.org
From: Greg Stein <gstein@lyra.org> All righty, then... here is your first appendix item: Thanks for the prompt response, Greg! Everyone else: Even though we aren't putting this in an appendix, I will be posting this info to our web page, so please send me your info. Now's your chance to advertise your option set so that you can nudge new implementations to support it! 24.xxx Subversion 1.0 (http://subversion.tigris.org/) A. Subversion client i. Required options: a. RFC 2518, Class 1 (but not Class 2) b. Core versioning (but not: VERSION-CONTROL, UNCHECKOUT, or SET-TARGET) c. Client-Workspace option d. Label option (probably; not entirely sure because our "label" may simply be a COPY) [ this also presumes Label will be split from Client-WS ] Yes, the label option is split from client-ws option. I think you'll end up wanting to support the baseline option instead of the label option, but that is of course up to you. e. Activity option f. Version-History-Resource option g. Version-Controlled-Collection option h. Fork-Control option i. Subversion-specific items: a custom report, I'd be interested in hearing about the custom report. DAV:version-name must be an integer representing repository-global-change, DAV:version-name is server defined, so that can be whatever you want it to be. atomic CHECKIN of activities, I added atomic checkin of activities in the MERGE request, so that's now part of the activity option. DAV:prop supported within the DAV:checkin element (to enable returning post-checkin information, such as new version resource URLs), I believe you can get this information by using a property REPORT on the DAV:version-set of the activity. We should verify this. possibly other TBD items??? Yeah, there always are those (:-). ii. Supported options: none B. Subversion server support i. RFC 2518, Class 1 ii. Subversion-specific subsets for each of 24.xxx.A.i.[b-i] The Subversion server will not fully support DeltaV's Core or Options. And yes, I realize that the above spec implies that neither the client nor the server will be interoperable with other DAV systems. That support will take place in a future version (after 1.0). Limited subsets will be available, so interop will depend highly upon what the client expects and uses from the server. UNCHECKOUT and SET-TARGET are no longer in core, and since Subversion auto-version-controls, you actually *do* support VERSION-CONTROL (i.e. applying VERSION-CONTROL to something that is already version-controlled is explicitly OK and required behavior). So that means you will be a fully compliant core versioning server (not quite as good as a fully operational death-star, but less susceptible to rebel bombing runs :-). In particular, this should give you a non-trivial degree of interoperability in even your 1.0 server. Cheers, Geoff
Received on Thursday, 21 December 2000 11:33:32 UTC