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


Reply via email to