On Feb 9, 2012 1:29 PM, "Philip Martin" <philip.mar...@wandisco.com> wrote: > > Johan Corveleyn <jcor...@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
