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.
Received on 2013-02-15 13:12:47 CET