Re: GitHub svn bridge corrupting working copies

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?
Received on 2017-10-15 21:00:27 CEST