RE: Speed issues with ra_neon to remote repositories

> > Well, it's good to know development effort is being spent on
> improving
> > HTTP Subversion access, especially as it seems that svn:// access
> is
> > very much downplayed (and not developed?).
>
> What's missing for svn:// which needs to be developed?
>
> It supports quick and simple setup and SSH encryption.
> That's what it's for. All the "heavy" features are left for HTTP.
> E.g. svnserve can't even bind to more than one IP address,
> unless it's being run by inetd.

IMHO svnserve misses one very important feature: LDAP authentication.

See this thread for those who think you can use LDAP via svnserve+SASL:
http://svn.haxx.se/users/archive-2009-06/0536.shtml

I must say that I was quite disappointed, when searching the mailinglist archives, to see that a patch to get LDAP support directly into svnserve (without SASL) was rejected:
http://svn.haxx.se/dev/archive-2008-02/0081.shtml

I can understand the dev's arguments about increased maintenance cost etc., but this is just such an important feature. Maybe nobody at the time realized that svn+SASL+LDAP just doesn't work ...

In a commercial setting, being able to authenticate with LDAP (often more specifically AD) is essential. In a lot of companies, every service provided by IT authenticates with that single LDAP. Users only need one password to access all kinds of things (logging in into your pc, accessing the wiki, intranet, extranet, ...). If you change your password in Windows (which you have to do every X months), it's changed in the LDAP, so it's changed for all those services. It's your "company password" that you use for all IT stuff in the company.

You'd have a very hard time convincing the IT department to set up a separate (cleartext/obfuscated) database with passwords, separate from the LDAP, just to set up SVN. Are they going to keep it in sync with the LDAP (with some script-fu), or do your developers need to have another specific password, just for SVN (and how will you let them change it etc)?

For us this was a deal-breaker to use svnserve. We had no choice but to go for apache+svn in the end. This is ok, but in reality this means: svnserve is not usable in a company setting.

Regards,
Johan

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2365241

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-06-25 13:56:04 CEST