subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Schmidt <subversion-2...@ryandesign.com>
Subject Re: GitHub svn bridge corrupting working copies
Date Sun, 15 Oct 2017 19:00:10 GMT
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?



Mime
View raw message