Thanks for your suggestions!
On Oct 15, 2017, at 13:07, Daniel Shahaf wrote: > 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? Nothing unusual; just modifying one file and adding another: https://github.com/macports/macports-ports/commit/2198debd25b02bcf7f6b17f79b415690449a85f0 > 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? svn log works fine: $ svn log -qvr r139308 https://github.com/macports/macports-ports/trunk ------------------------------------------------------------------------ r139308 | nicolas.pavillon | 2017-10-13 08:22:43 -0500 (Fri, 13 Oct 2017) Changed paths: M /trunk/kde/kdepimlibs4/Portfile A /trunk/kde/kdepimlibs4/files/patch-do_not_include_cpp.diff ------------------------------------------------------------------------ svnrdump errors: $ svnrdump dump https://github.com/macports/macports-ports/trunk -r 139308 --incremental SVN-fs-dump-format-version: 3 UUID: 0bf748bf-1d32-881d-ce5d-ce57b7db7bff svnrdump: E200007: The requested report is unknown. Same error on any revision I tried. Guess the bridge doesn't support svnrdump. (It doesn't support a lot of things, like blame.) Somehow I don't think specific revisions are the problem. I mean, I can now check out a new working copy at revision 139307 and successfully update it to 139308. Meanwhile, on our server, once, back in August, it encountered a corruption already halfway through the process of checking out a new working copy. And on the next checkout attempt it worked. >> 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 have not! I've fixed the working copy with one of your later suggestions; see below. >> 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. I have several corrupted working copies saved from the server-side script that I can try things on later. > You might be able to reproduce the problem by backdating your working > copy, 'svn up -r N-1 && svn up -r N kde'. Inside the kde directory, I ran: $ svn up -r 139306 Updating '.': At revision 139306. $ svn up -r 139307 Updating '.': At revision 139307. $ svn up -r 139308 Updating '.': UU kdepimlibs4/Portfile Skipped 'kdepimlibs4/files/patch-do_not_include_cpp.diff' -- An obstructing working copy was found Updated to revision 139308. Summary of conflicts: Skipped paths: 1 $ svn status $ rm -rf kdepimlibs4/files/patch-do_not_include_cpp.diff $ svn up -r 139308 Updating '.': Restored 'kdepimlibs4/files/patch-do_not_include_cpp.diff' A /path/to/macports-ports-trunk/patch-do_not_include_cpp.diff Updated to revision 139308. $ svn up Updating '.': At revision 139412. So at this point, the working copy seems to be fixed. >> 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. I'd like to try this but I'm not very familiar with the svn code. In subversion/libsvn_client/update.c I replaced "SVN_ERR(svn_ra_do_update3(...))" with "SVN_ERR(svn_delta__get_debug_editor(svn_ra_do_update3(...)))" but now svn segfaults when I update, so that must not have been right. Could you give more guidance on how to do this properly?
