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. > > Is this problem reproducible on a clean checkout from the same base revision?
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: > >> 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. 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 info patch-do_not_include_cpp.diff Path: patch-do_not_include_cpp.diff Name: patch-do_not_include_cpp.diff Working Copy Root Path: /Users/rschmidt/macports/macports-ports-svn-trunk URL: https://github.com/macports/macports-ports/trunk/patch-do_not_include_cpp.diff Relative URL: ^/trunk/patch-do_not_include_cpp.diff Repository Root: https://github.com/macports/macports-ports Repository UUID: 0bf748bf-1d32-881d-ce5d-ce57b7db7bff Revision: 140783 Node Kind: file Schedule: normal Last Changed Author: nicolas.pavillon Last Changed Rev: 139308 Last Changed Date: 2017-10-13 08:22:43 -0500 (Fri, 13 Oct 2017) Text Last Updated: 2017-10-15 13:35:55 -0500 (Sun, 15 Oct 2017) Checksum: 2a8a228c0febb014a18a90066cc944c43e70e89e $ svn log patch-do_not_include_cpp.diff svn: E160013: '/macports/macports-ports/!svn/bc/140783/trunk/patch-do_not_include_cpp.diff' path not found $ cd net $ svn st patch-plugins-check_load.c.diff $ svn info patch-plugins-check_load.c.diff Path: patch-plugins-check_load.c.diff Name: patch-plugins-check_load.c.diff Working Copy Root Path: /Users/rschmidt/macports/macports-ports-svn-trunk URL: https://github.com/macports/macports-ports/trunk/net/patch-plugins-check_load.c.diff Relative URL: ^/trunk/net/patch-plugins-check_load.c.diff Repository Root: https://github.com/macports/macports-ports Repository UUID: 0bf748bf-1d32-881d-ce5d-ce57b7db7bff Revision: 140783 Node Kind: file Schedule: normal Last Changed Author: nicolas.pavillon Last Changed Rev: 140759 Last Changed Date: 2017-11-22 22:33:27 -0600 (Wed, 22 Nov 2017) Text Last Updated: 2017-11-22 22:57:35 -0600 (Wed, 22 Nov 2017) Checksum: 8618a8b2da28a5123c6591314d67c537d9e43d4f $ svn log patch-plugins-check_load.c.diff svn: E160013: '/macports/macports-ports/!svn/bc/140783/trunk/net/patch-plugins-check_load.c.diff' path not found
github-svn-bridge.txt.gz
Description: GNU Zip compressed data
