Re: svn commit: r12393 - trunk/subversion/libsvn_client

[kf...@collab.net]

maxb@tigris.org writes:
> Log:
> Revert r12273, replacing it with a better fix to svn_client_ls erroneously
> reporting 'not found' in reponse to an explicit ls of a file whose name
> contains URI-unsafe characters, which fixes the problem when invoked
> on an URL instead of a WC path, too.
> 
> * subversion/libsvn_client/ls.c (svn_client_ls2): Form the basename by
>     splitting the last component off the canonicalized URL,
>     and URI-decoding it.

At first I was worried this wouldn't address the issues described in
this thread:

http://subversion.tigris.org/servlets/BrowseList?list=dev&by=thread&from=267545

But...

> --- trunk/subversion/libsvn_client/ls.c	(original)
> +++ trunk/subversion/libsvn_client/ls.c	Sat Dec 18 21:35:43 2004
> @@ -111,15 +111,12 @@
>        const char *parent_url, *base_name;
>        svn_dirent_t *the_ent;
>  
> -      /* Split 'url' to get the parent, but split 'path_or_url' to get
> -         the basename.  We're going to use the former as a URL, but
> -         the latter as a non-URL.  If any URI-encoding happened in the
> -         earlier conversion from 'path_or_url' to 'url', we want the
> -         effects reflected in 'parent_url' but not in 'base_name'. */
> -      svn_path_split (url, &parent_url, NULL, pool);
> -      svn_path_split (path_or_url, NULL, &base_name, pool);
> -
>        /* Re-open the session to the file's parent instead. */
> +      svn_path_split (url, &parent_url, &base_name, pool);
> +      /* 'base_name' is now the last component of an URL, but we want
> +         to use it as a plain file name. Therefore, we must URI-decode
> +         it. */
> +      base_name = svn_path_uri_decode(base_name, pool);
>        SVN_ERR (svn_client__open_ra_session (&session, ra_lib, parent_url,
>                                              NULL,
>                                              NULL, NULL, FALSE, TRUE, 

...then I realized that because 'base_name' comes from 'url' anyway
(not 'path_or_url'), url-decoding it is always legitimate.  Which
makes this a cleaner fix than what I was proposing in the above thread
anyway.  Thanks, Max.

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org