On Sat, May 19, 2012 at 9:58 PM, Greg Stein <gstein_at_gmail.com> 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
Received on 2012-05-21 13:48:25 CEST