On Wed, May 16, 2012 at 5:15 PM, C. Michael Pilato <[email protected]> wrote: > On 05/16/2012 06:46 AM, Greg Stein wrote: >> Short query: is this possible? > > I know of no convincing reason why we cannot someday delete libsvn_ra_neon. > I am very much in favor of getting back to a single DAV provider. I > believe that ra_serf offers us the best path forward along those lines, not > because it is demonstrably "better", but because it has our developer > inertia and we've a tighter cross-community connection with the Serf project > than we do the Neon project. > >> We have some issues filed against ra_serf. Which of them should be >> considered as blockers? > > Having not reviewed the issues myself, I can only submit the following > litmus test of ra_serf readiness: can it do everything that our current > user base expects ra_neon to do? I don't see any reason to make it more > complicated than that. I strongly wish to *not* have to tell any user, > "Sorry, you can't upgrade to Subversion 1.8 because we decided to drop > support for that Windows Kerberos NTLM Snozwaggle 8.2 support you were using > in ra_neon that ra_serf doesn't offer." Until that time, ra_neon must remain. > Serf has full Kerberos/NTLM implementation on Windows and *nix. So it's not issue. Probably implementation has some bugs, but I've used it for along time without serious issues.
I didn't tested but most likely serf doesn't support OpenSSL authentication using client certificates stored smart cards. But this is different issue than Kerberos/NTLM. -- Ivan Zhakov
