On Feb 9, 2012 1:29 PM, "Philip Martin" <philip.martin_at_wandisco.com> wrote:
> Johan Corveleyn <jcorvel_at_gmail.com> writes:
> > The "dangerous behavior" may have been present in 1.7.0 already, but
> > 1.7.3 will be the first release where this appeared to cause a real
> > issue. I mean, for some reason the bug (or manifestation of the
> > "lingering bug") first appeared on 1.7.x after r1239697 (backport of
> > r1237720 and r1239596 (stuff in mod_dav_svn/liveprops.c) from trunk).
> I've managed to reproduce the problem on my Linux box using a different
> dataset. Using r1239696, i.e. before the revision that triggers the
> regression test FAIL on your machine, I see:
> $ rm -rf repo && svnadmin create repo && \
> svnrdump dump -r840000:head http://localhost:8080/repos/asf \
> --config-option servers:global:http-library=serf | svnadmin load repo
> * adding path : subversion/trunk/ac-helpers/gnu-diff.sh ... done.
> svnadmin: E140001: Unrecognized record type in stream
> svnrdump: E135007: Write error in pipe
> A second run gives:
> svnadmin: E185003: Delta does not fill the target window
> * adding path : subversion/trunk/www/project_nav.html ...svnrdump:
E135007: Write error in pipe
> I get similar errors when I switch my server to mod_dav_svn 1.6.
> So the problem is simply that svnrdump doesn't work with serf.
Yeah... after our conversation on IRC, that seemed almost inevitable.
What happens when you set MAX_NR_CONNS (that's not the right symbol, but
close) in linsvn_ra_serf/update.c to 2 ? That should eliminate the
parallelism. If that succeeds, then maybe we can patch 1.7.x in some way to
allow svnrdump to set that max, yet keep multiple for regular
Received on 2012-02-09 19:55:57 CET