You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2015/09/21 23:14:32 UTC
Re: svn commit: r1704317 - in
/subversion/trunk/subversion/libsvn_ra_serf: commit.c options.c ra_serf.h
serf.c
kotkov@apache.org wrote on Mon, Sep 21, 2015 at 15:19:46 -0000:
> Author: kotkov
> Date: Mon Sep 21 15:19:40 2015
> New Revision: 1704317
>
> URL: http://svn.apache.org/viewvc?rev=1704317&view=rev
> Log:
> Use compressed svndiff1 format for deltas when committing changes over
> http:// and https://.
...
> So, we begin using compressed svndiff1 format in ra_serf, if that's possible.
> This is done for servers that advertise Subversion's HTTP v2 protocol, unless
> compression is disabled by the 'http-compression = no' client configuration
> option. Existing Apache HTTPd + mod_dav_svn servers know how to deal with
> svndiff1, starting from Subversion 1.4, but the reasoning behind enabling
> it with HTTP v2 is that if the user is stuck with the old protocol version,
> she probably does not really care about the performance. I tested existing
> custom implementations of Subversion's HTTP v2 protocol that are not based
> on mod_dav_svn, and they as well now how to deal with svndiff1 format.
...
> +++ subversion/trunk/subversion/libsvn_ra_serf/options.c Mon Sep 21 15:19:40
> 2015
> @@ -243,6 +243,20 @@ capabilities_headers_iterator_callback(v
> apr_hash_set(session->supported_posts, "create-txn", 10, (void *)1);
> }
>
> + /* Use compressed svndiff1 format for servers that speak HTTPv2.
> +
> + Apache HTTPd + mod_dav_svn servers support svndiff1, beginning
> + from Subversion 1.4, but they do not advertise this capability.
> + Compressing data can have a noticeable impact if the connection
> + is slow, and we want to use it even for existing servers, so we
> + send svndiff1 data to every HTTPv2 server (Subversion 1.7 and
> + greater).
> +
> + The reasoning behind enabling it with HTTPv2 is that if the user
> + is stuck with the old Subversion's HTTPv1 protocol, she probably
> + doesn't really care about performance. */
> + session->supports_svndiff1 = TRUE;
Perhaps invent an "I speak svndiff1" wire capability and make 1.10
servers advertise it? I get that the workaround implemented is
necessary for interoperating with released servers, but we could at
least do it right from now on.
Cheers,
Daniel
Re: svn commit: r1704317 - in /subversion/trunk/subversion/libsvn_ra_serf:
commit.c options.c ra_serf.h serf.c
Posted by Evgeny Kotkov <ev...@visualsvn.com>.
Daniel Shahaf <d....@daniel.shahaf.name> writes:
>> Makes sense. Something along these lines?
>
> +1
Committed in r1704891.
Regards,
Evgeny Kotkov
Re: svn commit: r1704317 - in
/subversion/trunk/subversion/libsvn_ra_serf: commit.c options.c ra_serf.h
serf.c
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Evgeny Kotkov wrote on Tue, Sep 22, 2015 at 15:54:01 +0300:
> Daniel Shahaf <d....@daniel.shahaf.name> writes:
>
> > Perhaps invent an "I speak svndiff1" wire capability and make 1.10
> > servers advertise it? I get that the workaround implemented is
> > necessary for interoperating with released servers, but we could at
> > least do it right from now on.
>
> Makes sense. Something along these lines?
+1
Re: svn commit: r1704317 - in /subversion/trunk/subversion/libsvn_ra_serf:
commit.c options.c ra_serf.h serf.c
Posted by Evgeny Kotkov <ev...@visualsvn.com>.
Daniel Shahaf <d....@daniel.shahaf.name> writes:
> Perhaps invent an "I speak svndiff1" wire capability and make 1.10
> servers advertise it? I get that the workaround implemented is
> necessary for interoperating with released servers, but we could at
> least do it right from now on.
Makes sense. Something along these lines?
[[[
Index: subversion/include/svn_dav.h
===================================================================
--- subversion/include/svn_dav.h (revision 1704592)
+++ subversion/include/svn_dav.h (working copy)
@@ -386,7 +386,16 @@ extern "C" {
#define SVN_DAV_NS_DAV_SVN_REVERSE_FILE_REVS\
SVN_DAV_PROP_NS_DAV "svn/reverse-file-revs"
+/** Presence of this in a DAV header in an OPTIONS response indicates
+ * that the transmitter (in this case, the server) knows how to handle
+ * svndiff1 format encoding.
+ *
+ * @since New in 1.10.
+ */
+#define SVN_DAV_NS_DAV_SVN_SVNDIFF1\
+ SVN_DAV_PROP_NS_DAV "svn/svndiff1"
+
/** @} */
/** @} */
Index: subversion/libsvn_ra_serf/options.c
===================================================================
--- subversion/libsvn_ra_serf/options.c (revision 1704592)
+++ subversion/libsvn_ra_serf/options.c (working copy)
@@ -226,6 +226,12 @@ capabilities_headers_iterator_callback(void *baton
{
session->supports_rev_rsrc_replay = TRUE;
}
+ if (svn_cstring_match_list(SVN_DAV_NS_DAV_SVN_SVNDIFF1, vals))
+ {
+ /* Use compressed svndiff1 format for servers that properly
+ advertise this capability (Subversion 1.10 and greater). */
+ session->supports_svndiff1 = TRUE;
+ }
}
/* SVN-specific headers -- if present, server supports HTTP protocol v2 */
@@ -243,7 +249,8 @@ capabilities_headers_iterator_callback(void *baton
apr_hash_set(session->supported_posts, "create-txn", 10, (void *)1);
}
- /* Use compressed svndiff1 format for servers that speak HTTPv2.
+ /* Use compressed svndiff1 format for servers that speak HTTPv2,
+ in addition to servers that send SVN_DAV_NS_DAV_SVN_SVNDIFF1.
Apache HTTPd + mod_dav_svn servers support svndiff1, beginning
from Subversion 1.4, but they do not advertise this capability.
Index: subversion/mod_dav_svn/version.c
===================================================================
--- subversion/mod_dav_svn/version.c (revision 1704592)
+++ subversion/mod_dav_svn/version.c (working copy)
@@ -152,6 +152,7 @@ get_vsn_options(apr_pool_t *p, apr_text_header *ph
apr_text_append(p, phdr, SVN_DAV_NS_DAV_SVN_INHERITED_PROPS);
apr_text_append(p, phdr, SVN_DAV_NS_DAV_SVN_INLINE_PROPS);
apr_text_append(p, phdr, SVN_DAV_NS_DAV_SVN_REVERSE_FILE_REVS);
+ apr_text_append(p, phdr, SVN_DAV_NS_DAV_SVN_SVNDIFF1);
/* Mergeinfo is a special case: here we merely say that the server
* knows how to handle mergeinfo -- whether the repository does too
* is a separate matter.
]]]
Regards,
Evgeny Kotkov