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
checkout/update/sync.
Cheers,
-g
Received on 2012-02-09 19:55:57 CET