First of all I'd suggest that you not reinvent the wheel that's already been done twice now and instead using a library that knows Subversion's DAV based protocol. Note that while Subversion is mostly WebDAV and DeltaV compatible, it does have non-standard extensions.
To that end I'd point you to JavaHL or SVNKit. JavaHL comes with Subversion and uses JNI to access the Subversion libraries. SVNKit is an independent Java only implementation and includes a couple different interfaces, including one that is JavaHL compatible. If the use of the native libraries by JavaHL doesn't present a problem for you I'd recommend this since you'll have the benefit of using the same libraries as nearly every Subversion client.
If however your goal is to understand how Subversion implements the protocol on top of WebDAV and DeltaV then perhaps you want to just use a generic WebDAV and DeltaV client library to help. I'd recommend that you refer to these documents that describe how WebDAV and DeltaV are implemented within Subversion.
One thing you might want to understand is that as of Subversion 1.7 we support what we refer to as HTTPv2. HTTPv2 varies somewhat from the DeltaV standard in particular. Instead of using MKACTIVITY
to start a transaction on the server we use a POST
. Which has a body with a syntax something like this:
(create-txn)
or
( create-txn-with-props (PROPNAME PROPVAL [PROPNAME PROPVAL ...])
The older style which you must use with MKACTIVITY
(and can use with the POST
if you use create-txn
instead of create-txn-with-props
) is to use a PROPPATCH
on the transaction or the working baseline URL.
The working baseline URL is used with MKACTIVITY
and the transaction URL is used with the POST.
When using MKACTIVITY
you have to use a PROPFIND
on the root URL to get the version-controlled-configuration
. Then do a CHECKOUT
against the URL you received in response to that PROPFIND
providing the activity-set
href
as the URL you used with MKACTIVITY
. You'll get the working baseline URL back as the Location
header from the CHECKOUT request. Which you can then use to issue a PROPPATCH
to apply the revision properties.
When using POST
, you get the transaction stub from the headers in the OPTIONS
request response, the transaction name from the SVN-Txn-Name
header in the response to the POST
, and execute a PROPPATCH
against the $transaction_stub/$transaction_name
URL.
Probably the best ways to figure all this out is to setup a Subversion server and do some commits while running Subversion through a debugging proxy server such as Charles. You can force the traffic through the proxy on the svn command line with these options --config-option servers:global:http-proxy-port=8888 --config-option servers:global:http-proxy-host=127.0.0.1
. If you want to see the old protocol you can include SVNAdvertiseV2Protocol off
in your http configuration.
In order to support the broadest range of Subversion servers you need to implement the HTTPv1 protocol, which has more round trips and is more difficult to implement. If you want to only implement HTTPv2 you'll be limited to supporting Subversion servers newer than 1.7. In order to use HTTPv2 with maximum compatibility you'll have to detect the presence from the OPTIONS
response.
As you can see it gets rather complicated so it's really not worth trying to write your own client if all you want to do is implement some basic functionality.