[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

GitHub svn bridge corrupting working copies

From: Ryan Schmidt <subversion-2016_at_ryandesign.com>
Date: Sun, 15 Oct 2017 12:49:53 -0500

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.)
Received on 2017-10-15 19:50:11 CEST

This is an archived mail posted to the Subversion Users mailing list.