Ben Walton wrote: > Fixing this locally to the use of the minimized url let me move on > farther but I then got another core dump. If it continues like this, it might be possible to get help from svn developers. E.g., I would love to see a nice summary of the relevant API changes, like so (except with more truth): Previously the svn_frob() function would accept a filename with spaces in it in its "path" argument. Only the svn_plugh() function and its relatives required escaped paths. And all functions returning paths would unescape them. With Subversion 1.7, passing a filename with a space in it to svn_frob() trips an assertion, so we have to escape the "path" argument. This requires ... changes in application code. Unfortunately, back in Subversion 1.6, svn_frob() escapes its argument, so an application modified as above will find its "path" argument to be double-escaped. There does not seem to be any way for applications to target both Subversion 1.6 and 1.7 without doing ... Subversion 1.8 should follow the following simple, consistent semantics when requested with a flag, which would allow me to easily target my code against both SVN >= 1.8 and <= 1.6 with a few "if" statements (forgetting 1.7 as if it were a bad dream). Or to put it another way: if getting git-svn to cooperate starts to prove difficult, maybe abstracting away from git and understanding what changed for libsvn callers in general could help. On one hand, it could help in making sure the guarantees that libsvn offers are well documented, stable in the future, and clear. On the other hand, it might make the appropriate changes to git more obvious. Sorry for the ramble. I wish I could offer a fix instead. Jonathan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html