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

Commit fails, and it's not the SSPI problem

From: Maurits van de Kamp <mvk_at_hitechnologies.nl>
Date: 2007-04-11 15:44:43 CEST

Hi all,

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.
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.

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).

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!

Maurits.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Wed Apr 11 15:45:32 2007

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

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