subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Schmidt <>
Subject Re: GitHub svn bridge corrupting working copies
Date Thu, 23 Nov 2017 19:00:50 GMT

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 (
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
Relative URL: ^/trunk/patch-do_not_include_cpp.diff
Repository Root:
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
Relative URL: ^/trunk/net/patch-plugins-check_load.c.diff
Repository Root:
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

View raw message