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

Re: svn commit: r1533392 - in /subversion/trunk/subversion: libsvn_client/list.c libsvn_ra_svn/client.c

From: Stefan Fuhrmann <stefan.fuhrmann_at_wandisco.com>
Date: Fri, 18 Oct 2013 18:20:33 +0200

On Fri, Oct 18, 2013 at 5:44 PM, Bert Huijben <bert_at_qqmail.nl> wrote:

>
>
> > -----Original Message-----
> > From: stefan2_at_apache.org [mailto:stefan2_at_apache.org]
> > Sent: vrijdag 18 oktober 2013 13:22
> > To: commits_at_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.
Received on 2013-10-18 18:21:13 CEST

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