On 4/11/07, Maurits van de Kamp <mvk@hitechnologies.nl> wrote:
> We're having a strange problem here. One of our developers suddenly
> can't commit using TortoiseSVN anymore. This problem occurred without
> any changes to his workstation (as far as we know) nor the svn server.
Good you said "as far as we know" :)
Because let's face it: if something worked before and doesn't anymore,
at least *something* must have been changed.
> He was using Tortoise 1.4.1 when it occurred, but upgrading to 1.4.3
> didn't help. The server was a Linuxbox running an older subversion
> (stupid RPM's) but upgrading it to 1.4.3 (from source) :) didn't help.
> The current situation is that everybody here is using TortoiseSVN 1.4.3
> against a single svn 1.4.3 linuxserver, and it works perfectly for
> everybody except this one guy.
That guy obviously has a bad karma :)
> The last attempts, still failing, are with Tortoise 1.4.3 in XP, an svn
> server 1.4.3 and apache2-2.2.3.20 on SuSE 10.2. The apache server has no
> sspi authentication enabled. There is no domain controller here and the
> Windows guest account is not enabled on any of our systems. The details
> below will also show that this problem doesn't seem to have anything to
> do with the SSPI authentication problem some people describe.
>
> The error given by Tortoise:
>
> Error: Commit failed (details follow)
> Error: Options request failed on <path>
> Error: Options of <path>: 200 OK (http://server)
>
>
> What I see in the apache access log, is a single OPTIONS-request,
> without authentication, to which the server returns
> a 401. Nothing more.
>
> The apache errorlog shows nothing at all during this action.
>
> When any of our other users commits (successfully), his Tortoise also
> sends an OPTIONS without authentication, then also receives a 401, but
> then immediately sends another OPTIONS with the correct username.
>
> The user who can't commit already tried to delete all Tortoise's
> authentication data but to no avail. He also tried to completely remove
> and reinstall Tortoise, again no change.
>
> When I turned off access control on the svn server altogether (by
> commenting out "require valid user" in subversion.conf), the nameless
> OPTION-request returned 200 instead of 401 but still Tortoise gave the
> same error! It seems this has got nothing to do with authentication at
> all, or indeed with the result of the OPTIONS request (which is totally
> different for a 200- or 401-case).
I think it has a little to do with authentication. And with your
server setup. See below.
> Now the strangest part is that when this user logs on to another machine
> with the same username (there is no central authentication here, just
> several machines with the same account names), it still doesn't work! So
> it has something to do with his username as well. (Windows usernames are
> the same as the svn login names but the passwords aren't).
>
> When the same guy creates another account on his OWN computer, it STILL
> doesn't work. So it's also a problem related to his computer. It then
> turned out that Tortoise doesn't even ask him for a login name before a
> commit. So he can't even do it as another user. (All other functions
> work fine btw).
>
> So, Tortoise simply craps out after the OPTIONS request no matter what,
> but only from this guy's computer or when he is logged in on another
> computer. I'm totally baffled here. :o)
>
> Is there some way to get extra debug output from Tortoise? Like, what's
> it sending in the OPTIONS request and what is it getting back (besides
> the error code)?
>
> Any help is greatly appreciated!
I think you might have messed up the Subversion setup on your server.
(yes, even the SuSE rpms don't get it right :( ).
My best guess would be that this particular user has a username which
has non-ASCII chars in it, and maybe even the computer he's working on
has such a name. This isn't a problem for Subversion it it's correctly
set up. However, if it isn't, then you'll get a behavior like this
(which doesn't mean that's the only reason - maybe your problem is
something else).
* check your server setup, especially the apr-iconv stuff. If
apr-iconv isn't there or can't be found by Subversion, any username
with non-ASCII char can't do anything anymore.
* check the apr_iconv_path env variable - it must point to the correct
version of apr-iconv (the one Subversion can use)
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Thu Apr 12 09:57:14 2007