Ryan Schmidt wrote on Sun, Oct 15, 2017 at 14:00:10 -0500:
> 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
Okay, so perhaps the problem has to do with revisions that add new
files.
> 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.
Indeed, there is little we can do without knowledge of the bridge.
There is any number of ways in which these observations might be
confounders.
> > 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 139308
> Updating '.':
> UU kdepimlibs4/Portfile
> Skipped 'kdepimlibs4/files/patch-do_not_include_cpp.diff' -- An obstructing working copy was found
That's interesting; why would there be an obstruction?
Maybe a file by this name already existed at some point, and was not
removed cleanly?
Or perhaps github reported the 'add' to the client twice?
On your build server you can try recording the output of 'svn status
--no-ignore' before the update; that will show whether the file existed
before the update.
> 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.
>
>
> >> 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.
That should have produced a compiler warning to the effect that
svn_ra_do_update3()'s return type is different to the type of the first
formal argument to svn_ra_do_update3().
> Could you give more guidance on how to do this properly?
Certainly. Try this:
[[[
--- subversion/libsvn_ra/ra_loader.c 2017-08-09 19:58:28.925998170 +0000
+++ - 2017-10-15 19:14:31.505187973 +0000
@@ -715,6 +715,9 @@ svn_ra_do_update3
{
SVN_ERR_ASSERT(svn_path_is_empty(update_target)
|| svn_path_is_single_path_component(update_target));
+ SVN_ERR(svn_delta__get_debug_editor(&update_editor, &update_baton,
+ update_editor, update_baton,
+ NULL, result_pool));
return session->vtable->do_update(session,
reporter, report_baton,
revision_to_update_to, update_target,
]]]
The "wrapping" here is that the update_editor->foo callbacks, after
the call, are functions that print to stderr and then invoke the
before-the-call update_editor->foo.
Sorry for the ambiguity.
Cheers,
Daniel
Received on 2017-10-15 21:28:43 CEST