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 <[email protected]> CollabNet <> www.collab.net <> Enterprise Cloud Development
signature.asc
Description: OpenPGP digital signature
