Johan Corveleyn wrote on Mon, Feb 06, 2012 at 22:48:21 +0100: > On Mon, Feb 6, 2012 at 10:21 PM, Johan Corveleyn <jcor...@gmail.com> wrote: > > On Mon, Feb 6, 2012 at 9:16 PM, Daniel Shahaf <danie...@elego.de> wrote: > >> Hyrum K Wright wrote on Mon, Feb 06, 2012 at 11:44:06 -0600: > >>> The question I have, which is more 1.7.3-centric, is "what changed on > >>> the 1.7.x branch to start this happening?" Perhaps answering that > >>> will help us know what needs to be done to fix the problem. > >>> > >> > >> Philip pointed out on IRC that the error first occured in: > >> http://ci.apache.org/builders/svn-slik-w2k3-x64-ra/builds/3698 > >> but didn't occur in the immediately-preceding build: > >> http://ci.apache.org/builders/svn-slik-w2k3-x64-ra/builds/3696 > >> > >> Looking at the list of changes (at the bottom of the former link), it > >> would be nice to know whether the error reproduces with r1239696 or > >> r1239697. > >> > >> (I've tried to ask buildbot do that, but it errored out on me.) > > > > I'm still testing, but what I can say already is that the problem is > > server-side: if I start my Apache with the modules / libraries of a > > trunk build, the error does not occur, not even with a 1.7.x@HEAD > > client. > > > > Maybe that explains why it can't be reproduced everywhere? > > Ok, on the 1.7.x branch, the problem (server-side, so mod_dav_svn) was > introduced with r1239697. With r1239696 the problem isn't there. > > The test fails with serf (any version) against mod_dav_svn-1.7.x@1239697 > > The test succeeds with serf (any version) against mod_dav_svn-1.7.x@1239696 >
Thanks. Does the test trigger the error message 680 ap_log_rerror(APLOG_MARK, APLOG_ERR, serr->apr_err, 681 resource->info->r, 682 "Can't fetch or compute MD5 checksum of '%s': " 683 "%s", 684 resource->info->repos_path, 685 serr->message); ? On what path? > I'm still looking into whether the problem was also present on trunk > (in r1237720 or r1239596, the two revision which were backported in > r1239697), and if so, what revision exactly introduced it, and which > one made it go away (it's not present on trunk@HEAD). > > -- > Johan
