On Fri, Feb 15, 2013 at 12:21:16PM +0100, Diggory Hardy wrote: > Dear list, > > I have an old checkout of an svn repo. This results in: > > L10036 mmBackend$ svn info > svn: E155036: Please see the 'svn upgrade' command > svn: E155036: Working copy '/home/dhardy/code/all/mmBackend' is too old > (format 10, created by Subversion 1.6) > L10036 mmBackend$ svn st > svn: E155036: Please see the 'svn upgrade' command > svn: E155036: Working copy '/home/dhardy/code/all/mmBackend' is too old > (format 10, created by Subversion 1.6) > L10036 mmBackend$ svn upgrade > svn: E155016: This working copy is corrupt and cannot be upgraded. Please > check out a new working copy. > svn: E155016: Bad base MD5 checksum for > '/home/dhardy/code/all/mmBackend/COPYING'; expected: > '46aaf69a91703493b666f212a04f2d8d'; found '94d55d512a9ba36caa9b7df079bae19f'; > > (As to why the checkout is corrupt, I have no idea. The files on my local > disk > are unlikely to have been corrupted.)
I would guess that some tool has fiddled with the pristine file in the .svn directory. This can happen if you use an external merge tool, for example, which gets passed the path to such files. If that ends up saving new content to the pristine file you'd see errors such as this. Obviously, nobody on this list is in the position to verify the expected and the actual checksum of the file. But if you could figure out why this mismatch is occurring it might shed some light on the problem. How does the file differ from the expected content? > Problem 1: what was the repo URL? Examining the files in .svn manually solves > this. Perhaps we could make the error message print the URL of the working copy root for such errors. It might not always be possible to do so but I agree that it would be a good idea to provide this information in a more convenient way. > Problem 2: what was the status of the repo (did I have uncommitted changes or > other local files)? I see no easy way of checking this. I'll try installing > an > old version of svn, but I don't find this a satisfactory solution, hence this > bug report. Installing the old client is indeed the recommended workaround. It is not very satisfactory for everyone, of course. But in many cases is it sufficient. Upgrading a working copy is a one-time operation and there is always the alternative of checking out a new one. Working copies are generally considered disposable so most people don't view this as a high priority issue. You should try to commit your existing local modifications with the old client before proceeding. > Ideally 'svn info' and 'svn st' should work on old checkouts without > requiring > any changes (upgrades or other) to them. I agree it would be nice if 'svn info' and 'svn status' were still working. But it wasn't implemented this way for 1.7. See http://subversion.apache.org/docs/release-notes/1.7.html#wc-upgrade """ Unfixable problems can arise from missing or corrupt meta-data inside .svn directories. Such damage to the 1.6 working copy is permanent, and cannot be fixed even if svn cleanup is run prior to the upgrade. We regret these limitations, but we had to introduce them in order for 1.7 to ship timely and without overcomplicating the internals. If your working copy does not upgrade cleanly, please check out a new one. """ Note that going forward, manual working copy upgrades will be required with 1.8 and later. There will be similar problems, due to the fact that we currently have no way of opening the sqlite database for reading without also upgrading its format. Implementing this would take more effort than anyone has been willing to spend. See the bottom of this post for related discussion: http://svn.haxx.se/dev/archive-2012-06/0456.shtml Basically we'd have to set aside a set of SQL queries that are safe to run without upgrading first and then deal with the implications this has on the system as a whole.
