Re: GitHub svn bridge corrupting working copies
From: Ryan Schmidt <subversion-2016_at_ryandesign.com>
Date: Thu, 23 Nov 2017 13:00:50 -0600
On Oct 16, 2017, at 08:01, Bert Huijben wrote:
> One probable cause for this would be that they somehow changed the revision number to hash mapping. I would hope they change the repository UUID in this case, but given how easy it is to change history in git, I wouldn't count on this.
The repository UUID does not change.
We don't allow changing history -- GitHub is configured to prohibit force-pushing to master -- so I am certain that is not occurring. We do allow force-pushing to pull requests before they're merged, but AFAIK pull requests are not stored in the main git repository so that shouldn't be a problem.
The same node corruption is not necessarily reproducible when a new working copy is checked out, but a different corruption occurs sometime later. Or, sometimes corruption occurs partway through the initial checkout, and trying another checkout a moment later works fine.
But I have several working copies of macports-ports that I have been using on my machine for awhile, and I have seen the some of the same corruption in multiple working copies. For example, a couple days ago, I updated one working copy and had problems with, among other directories, TeXShop3 and msp430-gcc-devel. I fixed that working copy by "svn up"ing the parent directory of those problem directories to a prior revision, then "svn up"ing back to HEAD. And now I have those same directories -- and others -- giving me problems in a separate working copy that had not been updated for awhile.
I'm attaching a terminal transcript of that session. It's long because the "svn up" pulled in 2 weeks worth of changes, and Subversion was compiled with the debugging change Daniel suggested. I took a working copy that had no uncommitted changes, and was last used to update boost and its dependents on November 10 (https://trac.macports.org/ticket/50671#comment:69) and ran "svn up". After pulling in some changes, it ended with "svn: E175002: REPORT request on '/macports/macports-ports/!svn/vcc/default' failed". "svn st" still showed nothing. Re-attempting "svn up" failed after 2 minutes with "svn: E175002: Unexpected HTTP status 504 'Gateway Timeout' on '/macports/macports-ports/!svn/vcc/default'". (GitHub support previously explained that when this happens, Subversion for whatever reason needs to compare all files in the working copy with the server, and the server takes too long to do that.) Then I ran "svn up" individually on all top-level items which revealed 19 separate directories experiencing the corruption (all of which are shown being updated in the first "svn up"). (But hundreds of other items were updated without complaint.)
Could you look at the debug output in the transcript and see if anything jumps out at you that would explain what's different about those 19 changes? If not, I wonder if corruption already happened earlier, and I should be making a new working copy, and occasionally running "svn up" on it, and saving all of the transcripts for later analysis.
On Oct 15, 2017, at 14:28, Daniel Shahaf wrote:
> Ryan Schmidt wrote on Sun, Oct 15, 2017 at 14:00:10 -0500:
Oh strange. In this working copy (not the one I submitted the transcript for above) I've just found this patchfile -- and another one -- elsewhere in the working copy. The client thinks it belongs there -- "svn st" shows nothing, and "svn info" shows information -- but "svn log" shows the server doesn't know about it, as of course it shouldn't, since that's not where it is on the server.
$ svn st patch-do_not_include_cpp.diff
$ svn log patch-do_not_include_cpp.diff
$ cd net
$ svn log patch-plugins-check_load.c.diff
|
This is an archived mail posted to the Subversion Users mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.