I'm posting here for feedback before opening an issue with the Subversion tracker.
Passing multiple URLs to 'svn delete' generates the following error when one or more of the URLs contains a URL-encoded space (i.e. %20): URL 'file:///Users/me/dev/repo/lib/tags/2.0.3.008%2520(R2.0.3)' does not exist The error has status 160013 and originates at subversion/libsvn_client/delete.c, 197 The actual URL specified to 'svn delete' was 'file:///Users/me/dev/repo/lib/tags/2.0.3.008%20(R2.0.3)', i.e. the name of the directory being deleted is '2.0.3.008 (R2.0.3)'. The error description indicates that 'svn delete' is double-encoding the URL, incorrectly replacing the '%' character from the URL-encoded space (i.e. %20) with %25, resulting in an incorrect URL. Specifying a single URL with a URL-encoded space to 'svn delete' works as expected. A cursory glance at the source for svn_client_delete3 and svn_path_condense_targets indicates that svn_path_condense_targets contains special-case handling for a single URL. This might explain why the double-encoding is not encountered when a single URL is specified to 'svn delete' and may indicate that svn_path_condense_targets is the source of the error. Other observations: * This appears to be a regression. I could not reproduce this error with 'svn' on the command line for the build of 1.6.5 included with Mac OS X 10.6.6. I also could not reproduce this when using the svn_client_delete2 API with a 1.6.6 static library we built from source. * This behavior seems to have been introduced at some point between 1.6.7 and 1.6.12. We have verified that the bug exists in 1.6.12 and is still in evidence in 1.6.16. We have not tested 1.6.7 - 1.6.11 explicitly. * This may not seem to be a particularly severe issue to users of the 'svn' command-line interface. However, we use the svn_client_delete2 API in our Mac svn product to allow the user to delete the selected files in a browser GUI which supports multiple selection. This makes it trivial for the user to delete multiple items from a repository in a single commit, and greatly increases the likelihood of users experiencing this issue. Best regards, Simon Wilson http://www.zennaware.com
