subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Schmidt <subversion-2...@ryandesign.com>
Subject GitHub svn bridge corrupting working copies
Date Sun, 15 Oct 2017 17:49:53 GMT
Hi, I'm sure this is GitHub's problem, because it happens only when accessing a git repository
through the GitHub Subversion bridge using the Subversion client, but it's been months since
I reported the problem to them and they haven't fixed it so I thought I'd ask here if anybody
has any idea how to try to debug this so that I can give them some better information to work
with.

I'm using Subversion 1.9.7 installed with MacPorts on macOS 10.12.6 "Sierra".

It's a working copy of the macports-ports repository, checked out as:

svn checkout https://github.com/macports/macports-ports/trunk macports-ports-trunk

Everything is fine for a random number of days, and then at some point "svn update" fails
with a message like this:

svn: E155010: The node '/path/to/macports-ports-trunk/kdepimlibs4' was not found.

There is not supposed to be any kdepimlibs4 directly inside trunk. In fact, it's inside the
kde directory which is in trunk.

I can successfully "svn update" all the top-level directories except for kde. I can commit
from other directories too. But to finally fix the problem, I have to throw away the working
copy and check out a new one. This is inconvenient because it's the one I do all my work in.

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, and is one that is supposed
to be inside one of the top-level directories, but the error message always shows it is looking
for it directly in trunk.

Doing work in the working copy is not required for the corruption to occur. Until recently,
we were using such an svn working copy in a server-side script which ran every half hour and
would only ever "svn update" it, then index it and copy it to an rsync server; this would
corrupt itself regularly, sometimes more than once a day.

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.

I assume the GitHub svn bridge has delivered an incorrect response to the client, the results
of which have been recorded somewhere in the .svn directory, presumably inside wc.db because
that's the only file in there, other than pristines, which matches a grep for "kdepimlibs4".
I've poked around at it in an SQLite viewer, but searching for records where local_relpath,
parent_relpath, or repos_path contain "kdepimlibs4" hasn't revealed any entries where it's
not prefixed with "kde".

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.

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.)



Mime
View raw message