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

Re: @ sign in folder/file/url and revision parser

From: Greg Thomas <thomasgd_at_omc.bt.co.uk>
Date: 2007-03-02 12:53:35 CET

On Fri, 02 Mar 2007 12:03:37 +0100, Rajko Albrecht
<ral@alwins-world.de> wrote:

>I'm the author of kdesvn and I've got the following bug-report:
>"Some of my directories need '@' symbols in them (as dictated by
>matlab object-oriented syntax), but when using kdesvn on that
>repository I get errors like "Syntax error parsing revision
>'dirname'", where the directory was named '@dirname'."
>So I checked it and saw it is a problem with subversion itself:
>ralbrecht@br:/tmp/testco/trunk$ svn mkdir test@mathlabsyntax
> A test@mathlabsyntax
>ralbrecht@br:/tmp/testco/trunk$ svn info test@mathlabsyntax
> svn: Syntax error parsing revision 'mathlabsyntax'
>Searched and saw: there exists an bugreport for similar problem:
>but got never fixed.

The bug you listed above has a fairly simple workaround - so it's not
exactly high priority.

>For me - and I'm sure not only for me - this is a big problem. And
>yes: I have no idea how this should fixed. For kdesvn itself I may
>setup a workaround (kde urls always give parameters as a real url
>parameter not with @ so I will translate @ to it url-encoding like
>space to %20) but this can not be solutions for other clients like
>commandline-svn or rapidsvn or tortoisesvn.

Your workaround is the 'right thing' to do. All svn paths should be
URL encoded - so a directory name of "test@mathlabsyntax" should be
passed to svn as "test%40mathlabsyntax" - e.g.
svn info test%40mathlabsyntax
at the command line, or when passing in through the API calls.

Where possible, svn tries to do the right thing when a URL is not
encoded, but it doesn't (can't) get it right all the time - e.g. is
test@HEAD a directory called "test@HEAD" or a directory called "test"
at the HEAD peg-revision? That's why the path should be URL encoded.


This post represents the views of the author and does
not necessarily accurately represent the views of BT.
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 2 12:54:26 2007

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.