Aptana 1.5 "svn: Error resolving case of"
Asked Answered
D

4

6

I've installed Aptana 1.5 today but after the install all my SVN projects give me an error like this when I try to commit, update, repair, etc:

Access is denied.  
svn: Error resolving case of 'C:\Users\Brayn\My Documents\Aptana Studio Workspace\PentruConstrucii'

I've uninstalled my previous version of aptana, reinstalled aptana 1.5, changed my workspace and it still gives me this error.

Do you know what could it be ?

Doublecheck answered 16/7, 2009 at 12:28 Comment(0)
P
8

"C:\Users" means Windows Vista or 7...
It may be related the way SVN handle Windows Vista symbolic link ("junction"): poorly, according to this ticket (also described in bug 3208):

This bug is reproducible 100% of the time.

1) If you invoke "svn delete" against a Windows Vista symbolic-link, such as "c:\documents and settings\<username>\my documents\<some path>" then Subversion will fail with "svn: Error resolving case of 'C:\Documents and Settings\<username>\my documents\<some path>"'"

2) If you set the current working directory to "c:\documents and settings\<username>\my documents\<some path>" and invoke "svn delete" against the local filename the operation succeeds flawlessly.

It may be related to some ACL rights preventing the SVN to access the data:

Subversion tries (via APR) to resolve the exact case of all paths passed to it. This fails because this specific example has a path that is unreadable in its path.
You can see this via:

C:\>cacls "c:\Documents and Settings"
C:\Documents and Settings
                          Everyone:(DENY)(special access:) FILE_READ_DATA

I know you are referencing C:\Users here, but may be SVN try internally the old path.

Procathedral answered 16/7, 2009 at 12:40 Comment(2)
This was in deed the case. After I've moved my Workspace to C:\ it worked perfectly. I didn't have this problem in 1.3 my previous Aptana version...Doublecheck
Alas, svn info C:\full\path\to\wc fails for me in just the same way. Only I am on Windows 7 (patched to the gills), and as far as I can tell there aren't any DENY-ed things for my effective user for any folders in that path. Besides, my user belongs to Administrators group. To workaround, I had to mess with UAC policy settings: disable AdminApproval mode, which effectively kills UAC. This is not a good way to fix a problem, but I had to move on.Hedgehop
C
20

I've had this exact same error display if I end a directory name with a \ from a cmd.exe shell:

C:\> svn co http://my/repo/ "C:\Work\My Repo\"
svn: Error resolving case of 'C:\Work\My Repo"'

C:\> svn co  http://my/repo/ "C:\Work\My Repo"
 U   C:\Work\My Repo
Checked out revision 13768.

I think it ends up interpreting the final \" as an escaped double-quote instead of a backslash and the end of the string.

Cockspur answered 11/3, 2011 at 20:19 Comment(2)
Aha! Thanks for pointing this out even if it wasn't what OP was looking for, it solved my problem!Seema
I just had a similar case where I had superfluous spaces at the end of an external declaration. Thanks to the "clear" and "helpful" error message I was able to resolve it after 30 minutes of googling and searching ...Lachus
P
8

"C:\Users" means Windows Vista or 7...
It may be related the way SVN handle Windows Vista symbolic link ("junction"): poorly, according to this ticket (also described in bug 3208):

This bug is reproducible 100% of the time.

1) If you invoke "svn delete" against a Windows Vista symbolic-link, such as "c:\documents and settings\<username>\my documents\<some path>" then Subversion will fail with "svn: Error resolving case of 'C:\Documents and Settings\<username>\my documents\<some path>"'"

2) If you set the current working directory to "c:\documents and settings\<username>\my documents\<some path>" and invoke "svn delete" against the local filename the operation succeeds flawlessly.

It may be related to some ACL rights preventing the SVN to access the data:

Subversion tries (via APR) to resolve the exact case of all paths passed to it. This fails because this specific example has a path that is unreadable in its path.
You can see this via:

C:\>cacls "c:\Documents and Settings"
C:\Documents and Settings
                          Everyone:(DENY)(special access:) FILE_READ_DATA

I know you are referencing C:\Users here, but may be SVN try internally the old path.

Procathedral answered 16/7, 2009 at 12:40 Comment(2)
This was in deed the case. After I've moved my Workspace to C:\ it worked perfectly. I didn't have this problem in 1.3 my previous Aptana version...Doublecheck
Alas, svn info C:\full\path\to\wc fails for me in just the same way. Only I am on Windows 7 (patched to the gills), and as far as I can tell there aren't any DENY-ed things for my effective user for any folders in that path. Besides, my user belongs to Administrators group. To workaround, I had to mess with UAC policy settings: disable AdminApproval mode, which effectively kills UAC. This is not a good way to fix a problem, but I had to move on.Hedgehop
D
3

Old question, but I had a related and similar problem with a solution that appears relevant to this:

My (unrelated electronic design automation) program was throwing svn: Error resolving case of "<blah blah> errors followed by what looked like my commit log message. I eventually figured out that some double quotes (") I was using for the log message was being interpreted as terminating the message, then the rest of my babbling was taken as input to svn. My solution was to just use single quotes instead.

For your case, it sounds like it could be your program (Aptana) could be screwing up because when it sees spaces in the path name, it encloses the path in quotes, possibly breaking something (redundant quotes?). It would be resolved when you just work in the root C:\ because there are no spaces in the WC root path ...\My Documents\....

Defect answered 19/7, 2010 at 18:36 Comment(0)
P
0

I had similar issue today. But in my case, I was using backward slash in path instead of forward slash. I got it working After correcting that.

Its also recommended that path to be given inside double quotes.

Palpitation answered 23/6, 2020 at 22:53 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.