On Sat, May 19, 2012 at 9:58 PM, Greg Stein <[email protected]> wrote: > So far, beyond Philip's concern about traffic/CPU tradeoff, and a > couple open issues... I think we're in good shape to pull the lever.
As I said elsethread, this is probably the best overview of open ra_serf blockers: http://subversion.tigris.org/issues/buglist.cgi?subcomponent=libsvn_ra_serf&issue_status=NEW&issue_status=STARTED&issue_status=REOPENED&target_milestone=1.8.0 For convenience, I'm pasting the current result of this query here: 3968: DEFAULT_HTTP_TIMEOUT is way too high for serf 3969: ra_serf should check for cancellation from loops around serf_context_run() 3979: chunked transfer encoding not always supported 3981: serf infinite loop over https 3993: serf corrupts wc by calling close_edit for an incomplete update-report 4008: URL-URL copy fails due to "unsupported feature" 4088: serf assertion with <Location /> 4106: serf checkout fails on XML escaped property names 4127: serf/v1 doesn't handle SVN_ERR_APMOD_BAD_BASELINE 4174: serf: checkout / export errors out with "svn: E730053: Error retrieving REPORT (730053)" 4175: ra_serf crashes on Windows with AVG 2012 Surf-Shield This doesn't actually include Philip's issue about traffic (3980), as that is marked 1.8-consider. Maybe some of those issues are already fixed (please mark them resolved then), or maybe some of those aren't really blocking (please adjust milestone then, and/or discuss their blocking-ness). Some of these issues may also be already "fixed in our heads", but that doesn't count :-) (e.g. serf-1.1 hasn't been released yet). Though we can be pretty sure those are under control and will be resolved when some switch is flipped ... I'm just noting these here for information. I don't have any fundamental objections against going "ra_serf-only", and I can certainly understand the desire to eliminate the http-client duality and all the overhead it causes ... So if it helps going forward, and if we can get ra_serf stable enough on the broad variety of platforms and client/server combinations that we need to support (see blockers above) ... I'm all for it. -- Johan
