Re: GitHub svn bridge corrupting working copies

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
Received on 2017-10-15 20:07:43 CEST