On 10/18/2013 12:20 PM, Stefan Fuhrmann wrote: > On Fri, Oct 18, 2013 at 5:44 PM, Bert Huijben <b...@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.
