Johan Corveleyn <jcor...@gmail.com> writes: > I actually don't see anything either in the Apache error log (except > the child process starting up etc). Or should I look somewhere else?
The error log is the right place. > Just to add some more info: I can't reproduce with mod_dav_svn from > trunk@1237720 or trunk@1239596 (the two revisions which were > backported in r1239697). > > Makes me wonder whether something maybe went wrong during the backport > itself (merge conflict resolution)? Or the backported revisions > depended on something else which was not backported? The backport looks correct to me. One effect of the change is that the server no longer sends the bogus '###error###' MD5 checksum property. I suppose you could remove the svn_fs_check_path call at line 699 in subversion/mod_dav_svn/liveprops.c and set kind to svn_node_file to force the bogus property to be sent. > (the above findings may need to be confirmed by someone else though. > It's getting late here, and I'm trying all sorts of different > configurations, so I hope I haven't made any mistakes). If you want to try debugging the failing command then you can setup the test repository: svnadmin create repo svnadmin load repo < subversion/tests/cmdline/svnrdump_tests_data/mergeinfo_included_full.dump Setup Apache to serve that repository and then the command to debug is: svnrdump -q -r1:10 http://localhost.../repo -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com