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.
What to do about the commit Ev2 stuff? Perhaps you or Hyrum can help us
understand the scope of the performance cost paid by employing editor shims?
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Enterprise Cloud Development
Received on 2012-05-16 15:15:56 CEST