You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by st...@apache.org on 2013/10/18 13:22:22 UTC
svn commit: r1533392 - in /subversion/trunk/subversion: libsvn_client/list.c
libsvn_ra_svn/client.c
Author: stefan2
Date: Fri Oct 18 11:22:21 2013
New Revision: 1533392
URL: http://svn.apache.org/r1533392
Log:
Remove some unnecessary work from from our "ls" code.
* subversion/libsvn_client/list.c
(get_dir_contents): don't attempt to match locks when there are none
* subversion/libsvn_ra_svn/client.c
(ra_svn_get_dir): according to the protocol spec, we send the name
of the dirents (i.e. 1 segment) -- never a multi-
segment relpath. There is nothing to canonicalize.
Modified:
subversion/trunk/subversion/libsvn_client/list.c
subversion/trunk/subversion/libsvn_ra_svn/client.c
Modified: subversion/trunk/subversion/libsvn_client/list.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/list.c?rev=1533392&r1=1533391&r2=1533392&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_client/list.c (original)
+++ subversion/trunk/subversion/libsvn_client/list.c Fri Oct 18 11:22:21 2013
@@ -128,6 +128,10 @@ get_dir_contents(apr_uint32_t dirent_fie
}
SVN_ERR(err);
+ /* Locks will often be empty. Prevent pointless lookups in that case. */
+ if (locks && apr_hash_count(locks) == 0)
+ locks = NULL;
+
/* Filter out svn:externals from all properties hash. */
if (prop_hash)
prop_val = svn_hash_gets(prop_hash, SVN_PROP_EXTERNALS);
Modified: subversion/trunk/subversion/libsvn_ra_svn/client.c
URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_svn/client.c?rev=1533392&r1=1533391&r2=1533392&view=diff
==============================================================================
--- subversion/trunk/subversion/libsvn_ra_svn/client.c (original)
+++ subversion/trunk/subversion/libsvn_ra_svn/client.c Fri Oct 18 11:22:21 2013
@@ -1340,7 +1340,7 @@ static svn_error_t *ra_svn_get_dir(svn_r
SVN_ERR(svn_ra_svn__parse_tuple(elt->u.list, pool, "cwnbr(?c)(?c)",
&name, &kind, &size, &has_props,
&crev, &cdate, &cauthor));
- name = svn_relpath_canonicalize(name, pool);
+
dirent = svn_dirent_create(pool);
dirent->kind = svn_node_kind_from_word(kind);
dirent->size = size;/* FIXME: svn_filesize_t */
Re: svn commit: r1533392 - in /subversion/trunk/subversion: libsvn_client/list.c libsvn_ra_svn/client.c
Posted by Philip Martin <ph...@wandisco.com>.
"Bert Huijben" <be...@qqmail.nl> writes:
>> --- subversion/trunk/subversion/libsvn_ra_svn/client.c (original)
>> +++ subversion/trunk/subversion/libsvn_ra_svn/client.c Fri Oct 18 11:22:21
>> 2013
>> @@ -1340,7 +1340,7 @@ static svn_error_t *ra_svn_get_dir(svn_r
>> SVN_ERR(svn_ra_svn__parse_tuple(elt->u.list, pool, "cwnbr(?c)(?c)",
>> &name, &kind, &size, &has_props,
>> &crev, &cdate, &cauthor));
>> - name = svn_relpath_canonicalize(name, pool);
>> +
>
> Then most likely there is a difference between implementation and
> documentation
>
> svn ls -R path
>
> will use this function with deeper names.
>
> See list.c get_dir_contents(), which calls itself recursively with
> longer and longer components.
>
> And I'm pretty sure there are also third party clients that use this
> feature via their own usage of the ra layer.
Even if the docs and current implementation always provide a single
component we should still either canonicalize, or check and raise an
error, to defend against against misbehaving or malicious servers.
--
Philip Martin | Subversion Committer
WANdisco // *Non-Stop Data*
Re: svn commit: r1533392 - in /subversion/trunk/subversion:
libsvn_client/list.c libsvn_ra_svn/client.c
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Fri, Oct 18, 2013 at 6:38 PM, C. Michael Pilato <cm...@collab.net>wrote:
> On 10/18/2013 12:20 PM, Stefan Fuhrmann wrote:
> > On Fri, Oct 18, 2013 at 5:44 PM, Bert Huijben <bert@qqmail.nl
> > Then most likely there is a difference between implementation and
> > documentation
> >
> > svn ls -R path
> >
> > will use this function with deeper names.
> >
> > See list.c get_dir_contents(), which calls itself recursively with
> > longer and longer components.
> >
> > And I'm pretty sure there are also third party clients that use this
> > feature via their own usage of the ra layer.
> >
> >
> > That's what I originally thought as well. As it turns out,
> > the path gets combined above the RA layer in lib_client.
> >
> > I spent most of today figuring out why svn ls -R left
> > my laptop idle (see r1533530), so I had exactly the
> > use-case that you described.
>
> Bert, are you perhaps thinking of the *input* to svn_ra_get_dir(), which
> accepts a path relative to the session URL that can have an arbitrary
> number of components?
>
> Stefan is correct that -- at least in the case of our own libraries --
> the "name" parsed from the get-dir *response* should only be a single
> path component. (Its source is the svn_fs_dir_entries hash keys, which
> are single-component relpaths.)
>
> That said, Stefan, we made a conscious decision to sanitize paths on
> both sides of the wire because we don't control the wire itself. For
> example, your libsvn_ra_svn-wielding client might not be talking to
> 'svnserve', but to a third-party custom implementation of the Subversion
> server that speaks the 'svn' protocol. As such, there is an opportunity
> for malformed data to be returned, and the canonicalization protects our
> client (to a degree) from certain potentially problems there. If
> anything, an additional check should be *added* at that call site to
> verify that 'name' is, in fact, but a single path component.
>
This function does not receive paths. It is basically reading a
directory hash and the incoming names must be file / directory
names. r1533812 adds a check for that error condition.
-- Stefan^2.
Re: svn commit: r1533392 - in /subversion/trunk/subversion:
libsvn_client/list.c libsvn_ra_svn/client.c
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Fri, Oct 18, 2013 at 6:38 PM, C. Michael Pilato <cm...@collab.net>wrote:
> On 10/18/2013 12:20 PM, Stefan Fuhrmann wrote:
> > On Fri, Oct 18, 2013 at 5:44 PM, Bert Huijben <bert@qqmail.nl
> > Then most likely there is a difference between implementation and
> > documentation
> >
> > svn ls -R path
> >
> > will use this function with deeper names.
> >
> > See list.c get_dir_contents(), which calls itself recursively with
> > longer and longer components.
> >
> > And I'm pretty sure there are also third party clients that use this
> > feature via their own usage of the ra layer.
> >
> >
> > That's what I originally thought as well. As it turns out,
> > the path gets combined above the RA layer in lib_client.
> >
> > I spent most of today figuring out why svn ls -R left
> > my laptop idle (see r1533530), so I had exactly the
> > use-case that you described.
>
> Bert, are you perhaps thinking of the *input* to svn_ra_get_dir(), which
> accepts a path relative to the session URL that can have an arbitrary
> number of components?
>
> Stefan is correct that -- at least in the case of our own libraries --
> the "name" parsed from the get-dir *response* should only be a single
> path component. (Its source is the svn_fs_dir_entries hash keys, which
> are single-component relpaths.)
>
> That said, Stefan, we made a conscious decision to sanitize paths on
> both sides of the wire because we don't control the wire itself. For
> example, your libsvn_ra_svn-wielding client might not be talking to
> 'svnserve', but to a third-party custom implementation of the Subversion
> server that speaks the 'svn' protocol. As such, there is an opportunity
> for malformed data to be returned, and the canonicalization protects our
> client (to a degree) from certain potentially problems there. If
> anything, an additional check should be *added* at that call site to
> verify that 'name' is, in fact, but a single path component.
>
This function does not receive paths. It is basically reading a
directory hash and the incoming names must be file / directory
names. r1533812 adds a check for that error condition.
-- Stefan^2.
Re: svn commit: r1533392 - in /subversion/trunk/subversion: libsvn_client/list.c
libsvn_ra_svn/client.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 10/18/2013 12:20 PM, Stefan Fuhrmann wrote:
> On Fri, Oct 18, 2013 at 5:44 PM, Bert Huijben <bert@qqmail.nl
> Then most likely there is a difference between implementation and
> documentation
>
> svn ls -R path
>
> will use this function with deeper names.
>
> See list.c get_dir_contents(), which calls itself recursively with
> longer and longer components.
>
> And I'm pretty sure there are also third party clients that use this
> feature via their own usage of the ra layer.
>
>
> That's what I originally thought as well. As it turns out,
> the path gets combined above the RA layer in lib_client.
>
> I spent most of today figuring out why svn ls -R left
> my laptop idle (see r1533530), so I had exactly the
> use-case that you described.
Bert, are you perhaps thinking of the *input* to svn_ra_get_dir(), which
accepts a path relative to the session URL that can have an arbitrary
number of components?
Stefan is correct that -- at least in the case of our own libraries --
the "name" parsed from the get-dir *response* should only be a single
path component. (Its source is the svn_fs_dir_entries hash keys, which
are single-component relpaths.)
That said, Stefan, we made a conscious decision to sanitize paths on
both sides of the wire because we don't control the wire itself. For
example, your libsvn_ra_svn-wielding client might not be talking to
'svnserve', but to a third-party custom implementation of the Subversion
server that speaks the 'svn' protocol. As such, there is an opportunity
for malformed data to be returned, and the canonicalization protects our
client (to a degree) from certain potentially problems there. If
anything, an additional check should be *added* at that call site to
verify that 'name' is, in fact, but a single path component.
Re: svn commit: r1533392 - in /subversion/trunk/subversion: libsvn_client/list.c
libsvn_ra_svn/client.c
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 10/18/2013 12:20 PM, Stefan Fuhrmann wrote:
> On Fri, Oct 18, 2013 at 5:44 PM, Bert Huijben <bert@qqmail.nl
> Then most likely there is a difference between implementation and
> documentation
>
> svn ls -R path
>
> will use this function with deeper names.
>
> See list.c get_dir_contents(), which calls itself recursively with
> longer and longer components.
>
> And I'm pretty sure there are also third party clients that use this
> feature via their own usage of the ra layer.
>
>
> That's what I originally thought as well. As it turns out,
> the path gets combined above the RA layer in lib_client.
>
> I spent most of today figuring out why svn ls -R left
> my laptop idle (see r1533530), so I had exactly the
> use-case that you described.
Bert, are you perhaps thinking of the *input* to svn_ra_get_dir(), which
accepts a path relative to the session URL that can have an arbitrary
number of components?
Stefan is correct that -- at least in the case of our own libraries --
the "name" parsed from the get-dir *response* should only be a single
path component. (Its source is the svn_fs_dir_entries hash keys, which
are single-component relpaths.)
That said, Stefan, we made a conscious decision to sanitize paths on
both sides of the wire because we don't control the wire itself. For
example, your libsvn_ra_svn-wielding client might not be talking to
'svnserve', but to a third-party custom implementation of the Subversion
server that speaks the 'svn' protocol. As such, there is an opportunity
for malformed data to be returned, and the canonicalization protects our
client (to a degree) from certain potentially problems there. If
anything, an additional check should be *added* at that call site to
verify that 'name' is, in fact, but a single path component.
Re: svn commit: r1533392 - in /subversion/trunk/subversion:
libsvn_client/list.c libsvn_ra_svn/client.c
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Fri, Oct 18, 2013 at 5:44 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
> > -----Original Message-----
> > From: stefan2@apache.org [mailto:stefan2@apache.org]
> > Sent: vrijdag 18 oktober 2013 13:22
> > To: commits@subversion.apache.org
> > Subject: svn commit: r1533392 - in /subversion/trunk/subversion:
> > libsvn_client/list.c libsvn_ra_svn/client.c
> >
> > Author: stefan2
> > Date: Fri Oct 18 11:22:21 2013
> > New Revision: 1533392
> >
> > URL: http://svn.apache.org/r1533392
> > Log:
> > Remove some unnecessary work from from our "ls" code.
> >
> > * subversion/libsvn_client/list.c
> > (get_dir_contents): don't attempt to match locks when there are none
> >
> > * subversion/libsvn_ra_svn/client.c
> > (ra_svn_get_dir): according to the protocol spec, we send the name
> > of the dirents (i.e. 1 segment) -- never a multi-
> > segment relpath. There is nothing to canonicalize.
> >
> > Modified:
> > subversion/trunk/subversion/libsvn_client/list.c
> > subversion/trunk/subversion/libsvn_ra_svn/client.c
> >
> > Modified: subversion/trunk/subversion/libsvn_client/list.c
> > URL:
> >
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/lis
> > t.c?rev=1533392&r1=1533391&r2=1533392&view=diff
> > ==========================================================
> > ====================
> > --- subversion/trunk/subversion/libsvn_client/list.c (original)
> > +++ subversion/trunk/subversion/libsvn_client/list.c Fri Oct 18 11:22:21
> 2013
> > @@ -128,6 +128,10 @@ get_dir_contents(apr_uint32_t dirent_fie
> > }
> > SVN_ERR(err);
> >
> > + /* Locks will often be empty. Prevent pointless lookups in that case.
> */
> > + if (locks && apr_hash_count(locks) == 0)
> > + locks = NULL;
> > +
> > /* Filter out svn:externals from all properties hash. */
> > if (prop_hash)
> > prop_val = svn_hash_gets(prop_hash, SVN_PROP_EXTERNALS);
> >
> > Modified: subversion/trunk/subversion/libsvn_ra_svn/client.c
> > URL:
> > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_svn/c
> > lient.c?rev=1533392&r1=1533391&r2=1533392&view=diff
> > ==========================================================
> > ====================
> > --- subversion/trunk/subversion/libsvn_ra_svn/client.c (original)
> > +++ subversion/trunk/subversion/libsvn_ra_svn/client.c Fri Oct 18
> 11:22:21
> > 2013
> > @@ -1340,7 +1340,7 @@ static svn_error_t *ra_svn_get_dir(svn_r
> > SVN_ERR(svn_ra_svn__parse_tuple(elt->u.list, pool,
> "cwnbr(?c)(?c)",
> > &name, &kind, &size, &has_props,
> > &crev, &cdate, &cauthor));
> > - name = svn_relpath_canonicalize(name, pool);
> > +
>
> Then most likely there is a difference between implementation and
> documentation
>
> svn ls -R path
>
> will use this function with deeper names.
>
> See list.c get_dir_contents(), which calls itself recursively with longer
> and longer components.
>
> And I'm pretty sure there are also third party clients that use this
> feature via their own usage of the ra layer.
>
That's what I originally thought as well. As it turns out,
the path gets combined above the RA layer in lib_client.
I spent most of today figuring out why svn ls -R left
my laptop idle (see r1533530), so I had exactly the
use-case that you described.
-- Stefan^2.
Re: svn commit: r1533392 - in /subversion/trunk/subversion:
libsvn_client/list.c libsvn_ra_svn/client.c
Posted by Stefan Fuhrmann <st...@wandisco.com>.
On Fri, Oct 18, 2013 at 5:44 PM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
> > -----Original Message-----
> > From: stefan2@apache.org [mailto:stefan2@apache.org]
> > Sent: vrijdag 18 oktober 2013 13:22
> > To: commits@subversion.apache.org
> > Subject: svn commit: r1533392 - in /subversion/trunk/subversion:
> > libsvn_client/list.c libsvn_ra_svn/client.c
> >
> > Author: stefan2
> > Date: Fri Oct 18 11:22:21 2013
> > New Revision: 1533392
> >
> > URL: http://svn.apache.org/r1533392
> > Log:
> > Remove some unnecessary work from from our "ls" code.
> >
> > * subversion/libsvn_client/list.c
> > (get_dir_contents): don't attempt to match locks when there are none
> >
> > * subversion/libsvn_ra_svn/client.c
> > (ra_svn_get_dir): according to the protocol spec, we send the name
> > of the dirents (i.e. 1 segment) -- never a multi-
> > segment relpath. There is nothing to canonicalize.
> >
> > Modified:
> > subversion/trunk/subversion/libsvn_client/list.c
> > subversion/trunk/subversion/libsvn_ra_svn/client.c
> >
> > Modified: subversion/trunk/subversion/libsvn_client/list.c
> > URL:
> >
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/lis
> > t.c?rev=1533392&r1=1533391&r2=1533392&view=diff
> > ==========================================================
> > ====================
> > --- subversion/trunk/subversion/libsvn_client/list.c (original)
> > +++ subversion/trunk/subversion/libsvn_client/list.c Fri Oct 18 11:22:21
> 2013
> > @@ -128,6 +128,10 @@ get_dir_contents(apr_uint32_t dirent_fie
> > }
> > SVN_ERR(err);
> >
> > + /* Locks will often be empty. Prevent pointless lookups in that case.
> */
> > + if (locks && apr_hash_count(locks) == 0)
> > + locks = NULL;
> > +
> > /* Filter out svn:externals from all properties hash. */
> > if (prop_hash)
> > prop_val = svn_hash_gets(prop_hash, SVN_PROP_EXTERNALS);
> >
> > Modified: subversion/trunk/subversion/libsvn_ra_svn/client.c
> > URL:
> > http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_svn/c
> > lient.c?rev=1533392&r1=1533391&r2=1533392&view=diff
> > ==========================================================
> > ====================
> > --- subversion/trunk/subversion/libsvn_ra_svn/client.c (original)
> > +++ subversion/trunk/subversion/libsvn_ra_svn/client.c Fri Oct 18
> 11:22:21
> > 2013
> > @@ -1340,7 +1340,7 @@ static svn_error_t *ra_svn_get_dir(svn_r
> > SVN_ERR(svn_ra_svn__parse_tuple(elt->u.list, pool,
> "cwnbr(?c)(?c)",
> > &name, &kind, &size, &has_props,
> > &crev, &cdate, &cauthor));
> > - name = svn_relpath_canonicalize(name, pool);
> > +
>
> Then most likely there is a difference between implementation and
> documentation
>
> svn ls -R path
>
> will use this function with deeper names.
>
> See list.c get_dir_contents(), which calls itself recursively with longer
> and longer components.
>
> And I'm pretty sure there are also third party clients that use this
> feature via their own usage of the ra layer.
>
That's what I originally thought as well. As it turns out,
the path gets combined above the RA layer in lib_client.
I spent most of today figuring out why svn ls -R left
my laptop idle (see r1533530), so I had exactly the
use-case that you described.
-- Stefan^2.
RE: svn commit: r1533392 - in /subversion/trunk/subversion: libsvn_client/list.c libsvn_ra_svn/client.c
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: stefan2@apache.org [mailto:stefan2@apache.org]
> Sent: vrijdag 18 oktober 2013 13:22
> To: commits@subversion.apache.org
> Subject: svn commit: r1533392 - in /subversion/trunk/subversion:
> libsvn_client/list.c libsvn_ra_svn/client.c
>
> Author: stefan2
> Date: Fri Oct 18 11:22:21 2013
> New Revision: 1533392
>
> URL: http://svn.apache.org/r1533392
> Log:
> Remove some unnecessary work from from our "ls" code.
>
> * subversion/libsvn_client/list.c
> (get_dir_contents): don't attempt to match locks when there are none
>
> * subversion/libsvn_ra_svn/client.c
> (ra_svn_get_dir): according to the protocol spec, we send the name
> of the dirents (i.e. 1 segment) -- never a multi-
> segment relpath. There is nothing to canonicalize.
>
> Modified:
> subversion/trunk/subversion/libsvn_client/list.c
> subversion/trunk/subversion/libsvn_ra_svn/client.c
>
> Modified: subversion/trunk/subversion/libsvn_client/list.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/lis
> t.c?rev=1533392&r1=1533391&r2=1533392&view=diff
> ==========================================================
> ====================
> --- subversion/trunk/subversion/libsvn_client/list.c (original)
> +++ subversion/trunk/subversion/libsvn_client/list.c Fri Oct 18 11:22:21 2013
> @@ -128,6 +128,10 @@ get_dir_contents(apr_uint32_t dirent_fie
> }
> SVN_ERR(err);
>
> + /* Locks will often be empty. Prevent pointless lookups in that case. */
> + if (locks && apr_hash_count(locks) == 0)
> + locks = NULL;
> +
> /* Filter out svn:externals from all properties hash. */
> if (prop_hash)
> prop_val = svn_hash_gets(prop_hash, SVN_PROP_EXTERNALS);
>
> Modified: subversion/trunk/subversion/libsvn_ra_svn/client.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_svn/c
> lient.c?rev=1533392&r1=1533391&r2=1533392&view=diff
> ==========================================================
> ====================
> --- subversion/trunk/subversion/libsvn_ra_svn/client.c (original)
> +++ subversion/trunk/subversion/libsvn_ra_svn/client.c Fri Oct 18 11:22:21
> 2013
> @@ -1340,7 +1340,7 @@ static svn_error_t *ra_svn_get_dir(svn_r
> SVN_ERR(svn_ra_svn__parse_tuple(elt->u.list, pool, "cwnbr(?c)(?c)",
> &name, &kind, &size, &has_props,
> &crev, &cdate, &cauthor));
> - name = svn_relpath_canonicalize(name, pool);
> +
Then most likely there is a difference between implementation and documentation
svn ls -R path
will use this function with deeper names.
See list.c get_dir_contents(), which calls itself recursively with longer and longer components.
And I'm pretty sure there are also third party clients that use this feature via their own usage of the ra layer.
Bert
RE: svn commit: r1533392 - in /subversion/trunk/subversion: libsvn_client/list.c libsvn_ra_svn/client.c
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: stefan2@apache.org [mailto:stefan2@apache.org]
> Sent: vrijdag 18 oktober 2013 13:22
> To: commits@subversion.apache.org
> Subject: svn commit: r1533392 - in /subversion/trunk/subversion:
> libsvn_client/list.c libsvn_ra_svn/client.c
>
> Author: stefan2
> Date: Fri Oct 18 11:22:21 2013
> New Revision: 1533392
>
> URL: http://svn.apache.org/r1533392
> Log:
> Remove some unnecessary work from from our "ls" code.
>
> * subversion/libsvn_client/list.c
> (get_dir_contents): don't attempt to match locks when there are none
>
> * subversion/libsvn_ra_svn/client.c
> (ra_svn_get_dir): according to the protocol spec, we send the name
> of the dirents (i.e. 1 segment) -- never a multi-
> segment relpath. There is nothing to canonicalize.
>
> Modified:
> subversion/trunk/subversion/libsvn_client/list.c
> subversion/trunk/subversion/libsvn_ra_svn/client.c
>
> Modified: subversion/trunk/subversion/libsvn_client/list.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_client/lis
> t.c?rev=1533392&r1=1533391&r2=1533392&view=diff
> ==========================================================
> ====================
> --- subversion/trunk/subversion/libsvn_client/list.c (original)
> +++ subversion/trunk/subversion/libsvn_client/list.c Fri Oct 18 11:22:21 2013
> @@ -128,6 +128,10 @@ get_dir_contents(apr_uint32_t dirent_fie
> }
> SVN_ERR(err);
>
> + /* Locks will often be empty. Prevent pointless lookups in that case. */
> + if (locks && apr_hash_count(locks) == 0)
> + locks = NULL;
> +
> /* Filter out svn:externals from all properties hash. */
> if (prop_hash)
> prop_val = svn_hash_gets(prop_hash, SVN_PROP_EXTERNALS);
>
> Modified: subversion/trunk/subversion/libsvn_ra_svn/client.c
> URL:
> http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_ra_svn/c
> lient.c?rev=1533392&r1=1533391&r2=1533392&view=diff
> ==========================================================
> ====================
> --- subversion/trunk/subversion/libsvn_ra_svn/client.c (original)
> +++ subversion/trunk/subversion/libsvn_ra_svn/client.c Fri Oct 18 11:22:21
> 2013
> @@ -1340,7 +1340,7 @@ static svn_error_t *ra_svn_get_dir(svn_r
> SVN_ERR(svn_ra_svn__parse_tuple(elt->u.list, pool, "cwnbr(?c)(?c)",
> &name, &kind, &size, &has_props,
> &crev, &cdate, &cauthor));
> - name = svn_relpath_canonicalize(name, pool);
> +
Then most likely there is a difference between implementation and documentation
svn ls -R path
will use this function with deeper names.
See list.c get_dir_contents(), which calls itself recursively with longer and longer components.
And I'm pretty sure there are also third party clients that use this feature via their own usage of the ra layer.
Bert