Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When using the command line/terminal svn client, a colleague is getting "svn: OPTIONS of " [repo] "...authorization failed" error message when they attempt to checkout the repo to be their local working copy.

They used to be able to do this but have recently had to change their password (periodic routine security policy). And it stopped working. NOTE: The svn check command does ask for a password everytime (which they supply - i.e. their new one.)

BUT strangely they have no problem with Tortoise SVN, it works on that. They supply their usual login and new password and it works.

Our setup is a virtualised CentOS Linux machine with several Linux user accounts where development takes place and the SVN central repo is on a separate server, authentication is using our LDAP login (i.e. the same corporate login used to login to our Windows machines). We login as Linux users to our development server from our Windows machines, using standard terminal SSH tools, e.g. PuTTY or MobaXTerm or CygWin.

When I change my password I don't get the same problem, I am able to checkout.

I have seen many questions about this error message from searching various forums on google but none have provided me with a solution as yet.

One of the solutions I found suggests to clear or remove a local cache containing authentication, in a .subversion folder, we tried this but still the same problem. Also tried checking out to another folder.

So it seems we have clean out any trace of cached passwords but yet it still rejects.

Could there be another place on our CentOS Linux machine that caches the login What is meant by OPTIONS (could it be a setting somewhere on our development machine or on the SVN repo server?) Could it be a HTTP Proxy cache of my colleague's credentials stored somewhere - so we need to clear that when a password is changed?

(Mistakenly posted on superuser.com (which is about users), so closed it there and moved it here)

share|improve this question
2  
have you tried svn co <path_to_repo> <path_to_checkout_folder> --username user.name@your.company –  Ozair Kafray Jul 24 '12 at 10:51
    
+1 Thanks, yes, already have, but still unlucky (get same problem). –  therobyouknow Jul 24 '12 at 14:50

2 Answers 2

I bet Tortoise SVN is reading different configuration options than the CLI SVN. SVN can read its configuration from many different sources. I would try playing with settings like store-auth-creds in the per-user INI file or registry.

share|improve this answer
    
The root cause is most likely a character set issue. To explain, our SVN setup uses LDAP authentication meaning that the login/password we use for SVN is the same as what we use for our corporate Windows PC network account login, which popular convenient arrangement only needing one account for both. However, we usually set/update our password via the usual Windows password change (CTRL-ALT-DEL) and we believe that the ISO character set in Windows is different from that used for the SVN CLI in Linux. –  therobyouknow Aug 7 '12 at 14:56
    
Our password wouldn't work because it contained a pound symbol which can be interpreted differently under a different character set or key mapping in Windows LDAP password changing compared to Linux LPAP SVN authentication due to mismatch in character set used. –  therobyouknow Aug 7 '12 at 14:57
    
+1 Thanks @Matt S I think this is the right place to be looking. Update: With the great help of WanDisco (don't work for them but use their services) we believe it is an issue with key-mappings being different in Windows and Linux. Symbols such as the pound symbol can get interpreted differently. I have moved the accepted answer (sorry) to this new answer but your upvote still remains as you address the general problem area. I have upvoted some answers you gave on other subjects as consolation that I liked. Hope this is OK. –  therobyouknow Aug 7 '12 at 15:01
up vote 2 down vote accepted

The root cause is most likely a character set issue. To explain, our SVN setup uses LDAP authentication meaning that the login/password we use for SVN is the same as what we use for our corporate Windows PC network account login, which popular convenient arrangement only needing one account for both. However, we usually set/update our password via the usual Windows password change (CTRL-ALT-DEL) and we believe that the ISO character set in Windows is different from that used for the SVN CLI in Linux.

Our password wouldn't work because it contained a pound symbol which can be interpreted differently under a different character set or key mapping in Windows LDAP password changing compared to Linux LPAP SVN authentication due to mismatch in character set used. (Credit to WanDisco folk for assisting us with the investigation, in fairness we simultaneously arrived at the same conclusion while on a call, don't work for them but use their services, I should give credit where it's due.)

share|improve this answer
1  
+1 Wow that's an obscure one. Thanks for coming back and posting this for the next unlucky person to run into this. –  Matt S Aug 7 '12 at 15:02
    
+1 @Matt S thanks, the light-bulb came on during an investigation with WanDisco#s help, don't work for them (but use their products) but credit to their support in helping arrive at this conclusion. –  therobyouknow Aug 7 '12 at 15:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.