[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH v2] HTTPv2 allow client to control transaction name in protocol

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Mon, 07 Mar 2011 13:15:34 +0000

On Fri, 2011-03-04, Philip Martin wrote:
> Extend Subversion's v2 HTTP protocol to include URIs that allow the
> client to define the transaction name visible in on the wire.
>
> If the client sends, or a proxy injects, an SVN-VTxn-Name header with
> the POST request it defines the transaction name to be returned to the
> client in the POST response. If the client recieves the new
> SVN-VTxn-Name header it uses that name in the new URIs in the requests
> that make up the commit.
>
> By default the client will not send the new header.
>
> * subversion/mod_dav_svn/dav_svn.h
> (struct dav_svn_root): Add vtxn_name member.
> (dav_svn__get_vtxn_stub, dav_svn__get_vtxn_root_stub): New.
>
> * subversion/mod_dav_svn/mod_dav_svn.c
> (dav_svn__get_vtxn_stub, dav_svn__get_vtxn_root_stub): New.
>
> * subversion/mod_dav_svn/posts/create_txn.c
> (dav_svn__post_create_txn): Get vtxn_name from header, if sent, and
> store vtxn_name:txn_name mapping in the activity database.
>
> * subversion/mod_dav_svn/version.c
> (get_option): Add vtxn stub and vtxn root stub headers.
> (merge): Delete visible_txn_name:txn_name mapping after commit.
>
> * subversion/mod_dav_svn/repos.c
> (parse_vtxnstub_uri, parse_vtxnroot_uri): New.
> (special_subdirs): Add vtxn and vtxr.
> (remove_resource): Delete mapping when aborting the transaction.
>
> * subversion/libsvn_ra_serf/ra_serf.h
> (struct svn_ra_serf__session_t): Add vtxn_stub and vtxn_root_stub.
>
> * subversion/libsvn_ra_serf/commit.c
> (setup_post_headers): New.
> (post_headers_iterator_callback): Handle vtxn name header.
> (open_root): Set header_delegate.
>
> * subversion/libsvn_ra_serf/options.c
> (capabilities_headers_iterator_callback): Support vtxn stub and
> vtxn root stub headers.
>
> * subversion/libsvn_ra_neon/options.c
> (parse_capabilities): Support vtxn stub and vtxn root stub headers.
>
> * subversion/include/svn_dav.h
> (SVN_DAV_VTXN_STUB_HEADER, SVN_DAV_VTXN_ROOT_STUB_HEADER,
> SVN_DAV_VTXN_NAME_HEADER): New.
>
> * notes/http-and-webdav/http-protocol-v2.txt: Update.
>
> Index: notes/http-and-webdav/http-protocol-v2.txt
> ===================================================================
> --- notes/http-and-webdav/http-protocol-v2.txt (revision 1077861)
> +++ notes/http-and-webdav/http-protocol-v2.txt (working copy)
> @@ -128,6 +128,14 @@
> Various read- and write-type requests can be issued against
> these resources (MKCOL, PUT, PROPFIND, PROPPATCH, GET, etc.).
>
> + - alternate transaction resource (!svn/vtxn/VTXN-NAME)
> + alternate transaction root resource (!svn/vtxr/VTXN-NAME/[PATH])
> +
> + Alternative names for the transaction based on a virtual, or
> + visible, name supplied by the client when the transaction
> + was created. The client supplied name is optional, if not
> + supplied these resource names are not valid.
> +
> * Opening an RA session:
>
> ra_serf will send an OPTIONS request when creating a new
> @@ -220,12 +228,17 @@
>
> - no more need to "discover" the activity URI; !svn/act/ is gone.
>
> - - client no longer creates an activity UUID itself.
> + - client no longer needs to create an activity UUID itself.
>
> - instead, POST returns the name of the transaction it created,
> - which can then be appended to the transaction stub and
> - transaction root stub as necessary.
> + as TXN-NAME, which can then be appended to the transaction
> + stub and transaction root stub as necessary.
>
> + - if the client does choose to supply a UUID with the POST
> + request then the POST returns that UUID as VTXN-NAME, and the
> + client then uses that with the alternate transaction stub and
> + transaction root stub in subsequent requests.

One thing that's not 100% clear from the protocol doc update is whether
the server sends *both* txn names in response, or just the "V" version.
If it sends both, then we need to specify whether the client has to use
the "V" version or can choose to use either one, or can mix accesses
arbitrarily using either. I can't think of any reason the server would
need to send both, so can we keep things simple by specifying that it
doesn't?

Other parts of this doc may need updating:

 * Opening an RA session:
[...]
   Additionally, this response will contain some new URL stub values:

     SVN-Rev-Stub: /REPOS-ROOT/!svn/rev
     SVN-Rev-Root-Stub: /REPOS-ROOT/!svn/rvr
     SVN-Txn-Stub: /REPOS-ROOT/!svn/txn
     SVN-Txn-Root-Stub: /REPOS-ROOT/!svn/txr

Should it send "vtxn" and "vtxr" stubs too, or instead? (I don't
understand why the protocol needs to send these stubs explicitly at all:
is there some reason why these cannot just be constructed by the
client?)

 * Commits
[...]
   Specific new changes:

     - The activity-UUID-to-Subversion-txn-name abstraction is gone.
       We now expose the Subversion txn names explicitly through the
       protocol.
[...]
       - client no longer creates an activity UUID itself.

- Julian
Received on 2011-03-07 14:16:16 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.