You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by iv...@apache.org on 2013/01/08 10:20:55 UTC
svn commit: r1430185 - in /subversion/trunk/subversion: include/svn_dav.h
libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Author: ivan
Date: Tue Jan 8 09:20:54 2013
New Revision: 1430185
URL: http://svn.apache.org/viewvc?rev=1430185&view=rev
Log:
mod_dav_svn: Advertise if server supports sending properties in update
report in skelta mode.
* subversion/include/svn_dav.h
(SVN_DAV_NS_DAV_SVN_INLINE_PROPS): New.
* subversion/libsvn_ra_serf/options.c
(capabilities_headers_iterator_callback): Set
session->supports_inline_props to TRUE if server supports inline props.
* subversion/libsvn_ra_serf/ra_serf.h
(svn_ra_serf__session_t): Add supports_inline_props.
* subversion/mod_dav_svn/version.c
(SVN_DAV_NS_DAV_SVN_INLINE_PROPS): Advertise that inlined props are
supported by server.
Modified:
subversion/trunk/subversion/include/svn_dav.h
subversion/trunk/subversion/libsvn_ra_serf/options.c
subversion/trunk/subversion/libsvn_ra_serf/ra_serf.h
subversion/trunk/subversion/mod_dav_svn/version.c
Modified: subversion/trunk/subversion/include/svn_dav.h
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/include/svn_dav.h?rev=1430185&r1=1430184&r2=1430185&view=diff
==============================================================================
--- subversion/trunk/subversion/include/svn_dav.h (original)
+++ subversion/trunk/subversion/include/svn_dav.h Tue Jan 8 09:20:54 2013
@@ -317,6 +317,13 @@ extern "C" {
#define SVN_DAV_NS_DAV_SVN_EPHEMERAL_TXNPROPS\
SVN_DAV_PROP_NS_DAV "svn/ephemeral-txnprops"
+/** Presence of this in a DAV header in an OPTIONS response indicates
+ * that the transmitter (in this case, the server) supports serving properties
+ * inline in update editor when 'send-all' is 'false'. */
+#define SVN_DAV_NS_DAV_SVN_INLINE_PROPS\
+ SVN_DAV_PROP_NS_DAV "svn/inline-props"
+
+
/** @} */
/** @} */
Modified: subversion/trunk/subversion/libsvn_ra_serf/options.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_serf/options.c?rev=1430185&r1=1430184&r2=1430185&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_ra_serf/options.c (original)
+++ subversion/trunk/subversion/libsvn_ra_serf/options.c Tue Jan 8 09:20:54 2013
@@ -211,6 +211,11 @@ capabilities_headers_iterator_callback(v
SVN_RA_CAPABILITY_EPHEMERAL_TXNPROPS, APR_HASH_KEY_STRING,
capability_yes);
}
+
+ if (svn_cstring_match_list(SVN_DAV_NS_DAV_SVN_INLINE_PROPS, vals))
+ {
+ session->supports_inline_props = TRUE;
+ }
}
/* SVN-specific headers -- if present, server supports HTTP protocol v2 */
Modified: subversion/trunk/subversion/libsvn_ra_serf/ra_serf.h
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_serf/ra_serf.h?rev=1430185&r1=1430184&r2=1430185&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_ra_serf/ra_serf.h (original)
+++ subversion/trunk/subversion/libsvn_ra_serf/ra_serf.h Tue Jan 8 09:20:54 2013
@@ -239,6 +239,10 @@ struct svn_ra_serf__session_t {
accepts skelta requests (Off). If this value is On both options are
allowed. */
const char *server_allows_bulk;
+
+ /* Indicates if the server supports sending inlined props in update editor
+ * in skelta mode (send-all == 'false'). */
+ svn_boolean_t supports_inline_props;
};
#define SVN_RA_SERF__HAVE_HTTPV2_SUPPORT(sess) ((sess)->me_resource != NULL)
Modified: subversion/trunk/subversion/mod_dav_svn/version.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/mod_dav_svn/version.c?rev=1430185&r1=1430184&r2=1430185&view=diff
==============================================================================
--- subversion/trunk/subversion/mod_dav_svn/version.c (original)
+++ subversion/trunk/subversion/mod_dav_svn/version.c Tue Jan 8 09:20:54 2013
@@ -149,6 +149,7 @@ get_vsn_options(apr_pool_t *p, apr_text_
apr_text_append(p, phdr, SVN_DAV_NS_DAV_SVN_ATOMIC_REVPROPS);
apr_text_append(p, phdr, SVN_DAV_NS_DAV_SVN_PARTIAL_REPLAY);
apr_text_append(p, phdr, SVN_DAV_NS_DAV_SVN_INHERITED_PROPS);
+ apr_text_append(p, phdr, SVN_DAV_NS_DAV_SVN_INLINE_PROPS);
/* 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.
Re: svn commit: r1430185 - in /subversion/trunk/subversion:
include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by Ivan Zhakov <iv...@visualsvn.com>.
On Fri, Jan 18, 2013 at 7:56 PM, Mark Phippard <ma...@gmail.com> wrote:
> On Fri, Jan 11, 2013 at 11:27 AM, Ivan Zhakov <iv...@apache.org> wrote:
>> On Thu, Jan 10, 2013 at 12:24 AM, Mark Phippard <ma...@gmail.com> wrote:
>>> On Wed, Jan 9, 2013 at 3:22 PM, Ivan Zhakov <iv...@apache.org> wrote:
>>>> On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato <cm...@collab.net> wrote:
>>>>> On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
>>>>>> I'm thinking about interoperability between svn 1.8-serf client and
>>>>>> pre-1.8 server: currently we use non-bulk skelta mode and this leads
>>>>>> PROPFINDs and GETs for each file/directory. I've added option to
>>>>>> advertise inline props support to leave possibility to use bulk
>>>>>> (send-all) mode for pre-1.8 server by default, while relying on server
>>>>>> configuration for newer servers.
>>>>>
>>>>> Ah, I see. So the client can say, "If you're going to force me to do a
>>>>> zillion turnarounds, I'd rather take the all-in-one-response option,
>>>>> please." Seems reasonable.
>>>>>
>>>> Yes, that was my plan. The only argument that I found against this
>>>> approach that we will have many different modes depending of
>>>> server/client versions and configurations:
>>>>
>>>> client server behavior
>>>> 1.8.x-serf 1.8.x skelta-mode without
>>>> propfinds (unless configured by server)
>>>> 1.8.x-serf 1.7.x bulk-mode
>>>> 1.7.x-serf 1.7.x skelta-mode with propfinds
>>>> 1.7.x-neon 1.7.x bulk-mode
>>>>
>>>>
>>>> But it makes sense: upgrading only one part (server or client) doesn't
>>>> change network protocol, which is good thing IMHO.
>>>
>>> +1 from me.
>>>
>> Implemented in r1432139.
>
> I just tested this using a recent trunk version against a SVN 1.7.8
> server. One thing I noticed is that the client is still issuing a
> PROPFIND request for every folder. There was just the single REPORT
> request and no GET requests, but still a lot of PROPFIND requests.
>
> If the client issued the Neon-style REPORT request then shouldn't the
> response have contained everything it needed to avoid those PROPFIND
> requests?
Fixed in r1436236.
--
Ivan Zhakov
Re: svn commit: r1430185 - in /subversion/trunk/subversion:
include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by Mark Phippard <ma...@gmail.com>.
On Fri, Jan 11, 2013 at 11:27 AM, Ivan Zhakov <iv...@apache.org> wrote:
> On Thu, Jan 10, 2013 at 12:24 AM, Mark Phippard <ma...@gmail.com> wrote:
>> On Wed, Jan 9, 2013 at 3:22 PM, Ivan Zhakov <iv...@apache.org> wrote:
>>> On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato <cm...@collab.net> wrote:
>>>> On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
>>>>> I'm thinking about interoperability between svn 1.8-serf client and
>>>>> pre-1.8 server: currently we use non-bulk skelta mode and this leads
>>>>> PROPFINDs and GETs for each file/directory. I've added option to
>>>>> advertise inline props support to leave possibility to use bulk
>>>>> (send-all) mode for pre-1.8 server by default, while relying on server
>>>>> configuration for newer servers.
>>>>
>>>> Ah, I see. So the client can say, "If you're going to force me to do a
>>>> zillion turnarounds, I'd rather take the all-in-one-response option,
>>>> please." Seems reasonable.
>>>>
>>> Yes, that was my plan. The only argument that I found against this
>>> approach that we will have many different modes depending of
>>> server/client versions and configurations:
>>>
>>> client server behavior
>>> 1.8.x-serf 1.8.x skelta-mode without
>>> propfinds (unless configured by server)
>>> 1.8.x-serf 1.7.x bulk-mode
>>> 1.7.x-serf 1.7.x skelta-mode with propfinds
>>> 1.7.x-neon 1.7.x bulk-mode
>>>
>>>
>>> But it makes sense: upgrading only one part (server or client) doesn't
>>> change network protocol, which is good thing IMHO.
>>
>> +1 from me.
>>
> Implemented in r1432139.
I just tested this using a recent trunk version against a SVN 1.7.8
server. One thing I noticed is that the client is still issuing a
PROPFIND request for every folder. There was just the single REPORT
request and no GET requests, but still a lot of PROPFIND requests.
If the client issued the Neon-style REPORT request then shouldn't the
response have contained everything it needed to avoid those PROPFIND
requests?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn commit: r1430185 - in /subversion/trunk/subversion:
include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by Ivan Zhakov <iv...@apache.org>.
On Thu, Jan 10, 2013 at 12:24 AM, Mark Phippard <ma...@gmail.com> wrote:
> On Wed, Jan 9, 2013 at 3:22 PM, Ivan Zhakov <iv...@apache.org> wrote:
>> On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato <cm...@collab.net> wrote:
>>> On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
>>>> I'm thinking about interoperability between svn 1.8-serf client and
>>>> pre-1.8 server: currently we use non-bulk skelta mode and this leads
>>>> PROPFINDs and GETs for each file/directory. I've added option to
>>>> advertise inline props support to leave possibility to use bulk
>>>> (send-all) mode for pre-1.8 server by default, while relying on server
>>>> configuration for newer servers.
>>>
>>> Ah, I see. So the client can say, "If you're going to force me to do a
>>> zillion turnarounds, I'd rather take the all-in-one-response option,
>>> please." Seems reasonable.
>>>
>> Yes, that was my plan. The only argument that I found against this
>> approach that we will have many different modes depending of
>> server/client versions and configurations:
>>
>> client server behavior
>> 1.8.x-serf 1.8.x skelta-mode without
>> propfinds (unless configured by server)
>> 1.8.x-serf 1.7.x bulk-mode
>> 1.7.x-serf 1.7.x skelta-mode with propfinds
>> 1.7.x-neon 1.7.x bulk-mode
>>
>>
>> But it makes sense: upgrading only one part (server or client) doesn't
>> change network protocol, which is good thing IMHO.
>
> +1 from me.
>
Implemented in r1432139.
--
Ivan Zhakov
VisualSVN Team
Re: svn commit: r1430185 - in /subversion/trunk/subversion:
include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by Mark Phippard <ma...@gmail.com>.
On Wed, Jan 9, 2013 at 3:22 PM, Ivan Zhakov <iv...@apache.org> wrote:
> On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
>>> I'm thinking about interoperability between svn 1.8-serf client and
>>> pre-1.8 server: currently we use non-bulk skelta mode and this leads
>>> PROPFINDs and GETs for each file/directory. I've added option to
>>> advertise inline props support to leave possibility to use bulk
>>> (send-all) mode for pre-1.8 server by default, while relying on server
>>> configuration for newer servers.
>>
>> Ah, I see. So the client can say, "If you're going to force me to do a
>> zillion turnarounds, I'd rather take the all-in-one-response option,
>> please." Seems reasonable.
>>
> Yes, that was my plan. The only argument that I found against this
> approach that we will have many different modes depending of
> server/client versions and configurations:
>
> client server behavior
> 1.8.x-serf 1.8.x skelta-mode without
> propfinds (unless configured by server)
> 1.8.x-serf 1.7.x bulk-mode
> 1.7.x-serf 1.7.x skelta-mode with propfinds
> 1.7.x-neon 1.7.x bulk-mode
>
>
> But it makes sense: upgrading only one part (server or client) doesn't
> change network protocol, which is good thing IMHO.
+1 from me.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Re: svn commit: r1430185 - in /subversion/trunk/subversion:
include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by Ivan Zhakov <iv...@apache.org>.
On Thu, Jan 10, 2013 at 12:14 AM, C. Michael Pilato <cm...@collab.net> wrote:
> On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
>> I'm thinking about interoperability between svn 1.8-serf client and
>> pre-1.8 server: currently we use non-bulk skelta mode and this leads
>> PROPFINDs and GETs for each file/directory. I've added option to
>> advertise inline props support to leave possibility to use bulk
>> (send-all) mode for pre-1.8 server by default, while relying on server
>> configuration for newer servers.
>
> Ah, I see. So the client can say, "If you're going to force me to do a
> zillion turnarounds, I'd rather take the all-in-one-response option,
> please." Seems reasonable.
>
Yes, that was my plan. The only argument that I found against this
approach that we will have many different modes depending of
server/client versions and configurations:
client server behavior
1.8.x-serf 1.8.x skelta-mode without
propfinds (unless configured by server)
1.8.x-serf 1.7.x bulk-mode
1.7.x-serf 1.7.x skelta-mode with propfinds
1.7.x-neon 1.7.x bulk-mode
But it makes sense: upgrading only one part (server or client) doesn't
change network protocol, which is good thing IMHO.
--
Ivan Zhakov
VisualSVN Team
Re: svn commit: r1430185 - in /subversion/trunk/subversion: include/svn_dav.h
libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/09/2013 03:10 PM, Ivan Zhakov wrote:
> I'm thinking about interoperability between svn 1.8-serf client and
> pre-1.8 server: currently we use non-bulk skelta mode and this leads
> PROPFINDs and GETs for each file/directory. I've added option to
> advertise inline props support to leave possibility to use bulk
> (send-all) mode for pre-1.8 server by default, while relying on server
> configuration for newer servers.
Ah, I see. So the client can say, "If you're going to force me to do a
zillion turnarounds, I'd rather take the all-in-one-response option,
please." Seems reasonable.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Re: svn commit: r1430185 - in /subversion/trunk/subversion:
include/svn_dav.h libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by Ivan Zhakov <iv...@apache.org>.
On Tue, Jan 8, 2013 at 6:55 PM, C. Michael Pilato <cm...@collab.net> wrote:
> On 01/08/2013 04:20 AM, ivan@apache.org wrote:
>> Author: ivan
>> Date: Tue Jan 8 09:20:54 2013
>> New Revision: 1430185
>>
>> URL: http://svn.apache.org/viewvc?rev=1430185&view=rev
>> Log:
>> mod_dav_svn: Advertise if server supports sending properties in update
>> report in skelta mode.
>
> Ivan,
>
> What motivated this change? You have the server advertising a subfeature of
> the REPORT functionality, and the client noting this fact, but the client
> isn't actually using the note.
>
> Besides that, it kinda breaks from the pattern we use for REPORT response
> functionality, which is that the client says "I want you to respond in X
> fashion if possible" and the server, in its response, says either "Sure,
> here's my X-style response..." or just "Here's my [implied non-X-style]
> response". (See the "add_props_included" report baton member in
> libsvn_ra_serf/update.c, and the handling thereof.)
>
> The advertisement you've added seems only valuable if it would prevent a
> client from acting *at all* when the server does/doesn't support the inline
> properties. Was that your intent?
>
Hi Mike,
I'm thinking about interoperability between svn 1.8-serf client and
pre-1.8 server: currently we use non-bulk skelta mode and this leads
PROPFINDs and GETs for each file/directory. I've added option to
advertise inline props support to leave possibility to use bulk
(send-all) mode for pre-1.8 server by default, while relying on server
configuration for newer servers.
--
Ivan Zhakov
VisualSVN Team
Re: svn commit: r1430185 - in /subversion/trunk/subversion: include/svn_dav.h
libsvn_ra_serf/options.c libsvn_ra_serf/ra_serf.h mod_dav_svn/version.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 01/08/2013 04:20 AM, ivan@apache.org wrote:
> Author: ivan
> Date: Tue Jan 8 09:20:54 2013
> New Revision: 1430185
>
> URL: http://svn.apache.org/viewvc?rev=1430185&view=rev
> Log:
> mod_dav_svn: Advertise if server supports sending properties in update
> report in skelta mode.
Ivan,
What motivated this change? You have the server advertising a subfeature of
the REPORT functionality, and the client noting this fact, but the client
isn't actually using the note.
Besides that, it kinda breaks from the pattern we use for REPORT response
functionality, which is that the client says "I want you to respond in X
fashion if possible" and the server, in its response, says either "Sure,
here's my X-style response..." or just "Here's my [implied non-X-style]
response". (See the "add_props_included" report baton member in
libsvn_ra_serf/update.c, and the handling thereof.)
The advertisement you've added seems only valuable if it would prevent a
client from acting *at all* when the server does/doesn't support the inline
properties. Was that your intent?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development