Re: Branching for 1.4

Peter N. Lundblad wrote:

> diff/merge/blame can ignore whitespace and eol-style only changes.
> svnsync/replay
> svnserve is a real service on Windows.
> wc replacements, bug fixes.
> Lots of client bug fixes in diff (referring to malcolm's work)
> wc propcaching and other speed and space improvements
> svndiff1 format
> The -c option to diff and merge (minor, but anyway)
> The sws feature (http://www.red-bean.com/sws)

:)

> Use switch instead of recheckout when changing URLs of svn:externals.
> bdb 4.4 support (if it doesn't go into 1.3.x)
> Experimental serf support.
> svn diff --summarize

Is 1.4 going to use neon-0.26 instead of 0.25? If yes, I'd really like
to have one more feature added (can't do it myself, sorry):
Neon-0.26 has a new API to explicitely choose which authentication
methods are used. This new API should be put to good use in Subversion
to specifically activate/deactivate the SSPI authentication on Windows
(and maybe other auth methods on other OS too).
This is really an important feature to have. Because as it is right now,
SSPI is used whenever it is available. The Problem is that some servers
have the user "guest" active, and that means the authentication will
succeed every time with that user, but then later the authorization will
fail when the user tries to access the repository. Since SSPI auth is
always used, there is no fall back to basic authentication - the
operation simply will fail.

This is also a problem with the current Subversion CL client. I guess
the reason nobody has reported problems with that yet is that most users
accessing a repo with authentication against a windows domain are not
using the CL client. TSVN has deactivated the SSPI authentication on the
1.3.x line, because we received some reports for the 1.3.0RCx releases.
The only option to 'solve' these problems was to deactivate SSPI completely.

So it would be much much better if there was an option in the Subversion
'servers' config file where a user can deactivate the SSPI
authentication if required.

Yes, the whole problem could also be solved by deactivating the user
'guest' on the domain controller. But that's not always possible because
other apps inside a company might rely on that user account to be active.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org