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

Re: Tortoise 1.8: Try 'Integrated Windows auth' first, then try' basic auth': no longer working

From: Elias Gerber <eg_at_viscomvisual.com>
Date: Wed, 07 Aug 2013 13:10:33 +0200

On 07.08.2013 10:40, Elias Gerber wrote:
> On 07.08.2013 10:04, Simon Large wrote:
>> On 7 August 2013 08:53, Elias Gerber <eg_at_viscomvisual.com> wrote:
>>> Hello
>>> Since we've updated to tortoise 1.8 'Basic authentication' is no longer
>>> working: In our server (Visual SVN Server) we've set up to 'Use Windows
>>> authentication' and then checked
>>> 'Basic authentication'
>>> and
>>> 'Integrated Windows authentication'
>>> With Tortoise SVN Clients <= 1.7 we had the behavior that the clients
>>> first tried 'Integrated Windows authentication'. If that did not work,
>>> it tried 'Basic authentication': A pop-up message appeared, allowing us
>>> to enter username/password. We used that for clients that were not part
>>> of the Windows domain: The windows authentication failed (as the domain
>>> control could not be reached) and the user was able to do 'Basic
>>> authentication'.
>>> Since Tortoise SVN Client only 'Integrated Windows authentication' seems
>>> to work: Computers inside the domain can authenticate fine, without the
>>> need to enter username/password. But computers outside the domain can
>>> never enter username/password: We get a message-box about the
>>> certificate to accept, and then authentication just fails, without the
>>> possibility to enter username/password.
>>> With an 1.8 Tortoise SVN client we have this behavior if we try to
>>> connect to a visual svn server using svn v1.7 or v1.8.
>>> With a 1.7 Tortoise SVN client everything works, no matter if the svn
>>> server uses svn 1.7 or v1.8.
>>> We have cleared all "saved data", this does not resolve the problem.
>>> Anyone an idea?
>> Are you using 1.8.0 or 1.8.1? Some auth problems were fixed in 1.8.1,
>> though there may be more to come. Almost certainly this comes from a
>> change in subversion, which now uses serf in place of neon as the http
>> library. (serf was optional but not the default in 1.7, but in 1.8 it
>> is the only choice).
>> Simon
> We have the problem with the Client 1.8.0 and 1.8.1.
We also tested it without Tortoise, but with the "pure" Svn Command line
client: The same behaviour: If we do a simple 'svn checkout repo path'
svn.exe hangs after calling some routine in 'libapr_tsvn'. It eats all
cpu-time of one core and the memory usage constantly grows, I killed it
when it reached about 1 Gigabyte.

With Svn command line client v1.7 everything works.

Interesting: With Tortoise SVN Client v1.7, we tried both settings:

http-library = serf
and with
http-library = neon

It works for both versions, so I doublt it is only because of the change
from neon to serf (?)

Well, I'll probably move the SVN list.



To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-08-07 13:10:43 CEST

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.