Ryan Schmidt wrote on Sun, 15 Oct 2017 12:49 -0500: > And the problem will just occur again sometime later with a different node. > The node it complains about is always a directory that someone else committed > to recently, [...]
Have you looked at these commits? Is there anything unusual in them, e.g., do they involve renames? Try 'svn log -qvr N URL' and 'svnrdump dump -r N --incremental' (or is it '-r N:N+1'?) on those commits, does either command error out? > I can "rm -rf kde && svn update kde" it, which restores it from the > pristines, and then again fails to update it because of the corrupted node. Have you also tried 'svn up -r0 kde' and 'svn up --set-depth=exclude kde'? > I haven't tried to capture the network traffic. I haven't used such tools > before, so I'm unfamiliar with them, and I can't reproduce the problem on > demand so it seems problematic to try capturing all network traffic for days > until the problem happens to occur. Well, the next time you run into the problem, backup the working copy somewhere, so you'd be able to reproduce by restoring the backup and doing 'rm -rf kde && svn up' as you just mentioned. You might be able to reproduce the problem by backdating your working copy, 'svn up -r N-1 && svn up -r N kde'. > Thanks for any suggestions you might have! (Other than "use the git client > instead"; I've tried that for months and it doesn't seem to be compatible > with my brain.) If you're comfortable with rebuilding, you can try wrapping the "debug editor" (svn_delta__get_debug_editor()) around the update editor (svn_ra_do_update3()) to get a dump of the changes the server reports to the client. That debug output would be at a higher level than a wire dump. Cheers, Daniel
