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

Re: Subversion support (was: Re: proposed client and server options)

From: Geoffrey M. Clemm <geoffrey.clemm@rational.com>
Date: Thu, 21 Dec 2000 11:32:32 -0500 (EST)
Message-Id: <200012211632.LAA07109@tantalum.atria.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:39 GMT