Innocent bystander's question, before 1.8 starts to be cast in stone: what's the status of ra_serf? Will we (again) attempt to make serf the default in 1.8? I know there have been some ra_serf bugfixes since 1.7, but there are certainly still some important open issues (not to mention unkown problems because ra_serf hasn't had enough coverage and problems aren't always adequately reported).
If we want to make serf happen for 1.8, shouldn't we (as a community) spend more time on it then? I'd hate for us to end up in the same difficult situation as with the 1.7 release: trying to make it the default but then realizing shortly before release that it isn't stable enough (partly because it hadn't seen enough coverage, and people didn't report problems so they could be fixed etc, etc...). In spite of the request in the 1.7-release notes for users to try out serf and report problems [1], I haven't seen many new reports ... I think we need some kind of community decision whether or not we'll go for it this time. And if we go for ra_serf as the default, put much more effort into it to make it happen. Starting with agreeing on a set of requirements that we want to be satisfied before release, or something like that. FWIW: I personally think serf brings noticeable (performance) improvements for users (so it's not only a license/developer/... thing) [2]. But it's hard to measure, it depends on a lot of factors, and can differ between usecases. On the downside: it's not yet stable enough, and generates too many requests (generating too many logs on the server). So I still see ra_serf having a lot of potential, and I hope it will become the default one day... -- Johan [1] http://subversion.apache.org/docs/release-notes/1.7.html#serf [2] On a Solaris build machine @work (Solaris 10 on x86 on ESX, with 1.6.17 client, 1.5.4 server (sorry, old stuff)), most interactions with the svn server are a lot faster when using serf than with neon. Things like ls, cat, log, mergeinfo, ... are all a lot faster (like 150ms vs. 900ms). Unfortunately, I can't use serf in general, because checkouts and updates crash sometimes (yeah, I need to investigate more, and report those ... first need to reproduce with a 1.7 client ...). So in my scripts I sprinkle "config-options servers:global:http-library=serf" for all svn commands that I know will not crash (basically anything except checkout, export and update). That made our buildscripts a lot faster on this machine. I don't know the reason for this perf difference, I don't see it on our Windows clients, nor on a physical Solaris 10 sparc machine. Maybe something to do with TCPIP parameters, network stack, actual connectivity (they're all on the same LAN though) ... for some reason neon is very expensive on this machine ...