On 22 January 2003, Karl Fogel said:
:-) Don't worry, we'll get it solved. So far, we've had three reports
of checksums problems: yours, nas's, and Justin's. [...] Yours and
nas's symptoms are very similar, too. Whatever the problem is, we'll
get to the bottom of it, with a little digging.
No surprise there: Neil (NAS) and I are co-workers, and we're using the
same repository. Said repository has a fairly short history: it was
created last week with cvs2svn, went immediately into production use
(svn 0.16 and http everywhere), and had one ugly hiccup when I Ctrl-C'd
a running svnlook. Ran svnadmin recover on it, after which things
seemed to be fine (even though it took nearly two hours!). We're now in
the process of upgrading to svn 0.17 (0.17.1 in my case) and switching
from http to ra_svn. The move to 0.17 on the server has caused no end
of trouble.
Greg Ward gward@mems-exchange.org writes:
$ svn up
[...]
U memsnet/docroot/links/fabs.ht
A instrument
A instrument/test
svn: A checksum mismatch occurred
svn: (charset conversion failed)
What platform are you running the client on?
Debian 'unstable', with the client built locally from
subversion-r4503.tar.gz -- ie. 0.17.1). I'm pretty sure I uninstalled
all svn-related Debian packages --
dpkg -l '*subversion*' '*svn*' '*neon*' '*apache2*' '*apr*'
lists nothing. Wanted to make sure I was using only code from the
0.17.1 tarball.
[me, reporting a problem yesterday]
svn: A checksum mismatch occurred
svn: apply_window: checksum mismatch after applying text delta
(instrument/grabber/.svn/tmp/text-base/default.css.svn-base):
expected checksum: 32669b7770e5019e9bd5e8760e4b7f0a
actual checksum: 2e9ef1ab231b053336d93d5c19151abb
Good thing Neil saved a copy of the repository that was giving us
problems before he dumped/reloaded -- using the broken repos, I can
reproduce this error today. Here's what I did:
$ svn co http://.../broken/trunk broken-trunk
$ cd broken-trunk
$ rm -rf instrument
$ svn up
It failed exactly the same as yesterday -- good! So let's dig in...
[Karl]
How do the contents of
instrument/grabber/.svn/tmp/text-base/default.css.svn-base
look to you?
No such file. .svn/text-base contains the two files that were
successfully fetched in the update, and .svn/tmp/text-base is empty.
What about the one really in the repository? (Can you
retrieve the repos one by other means, so you can compare them?)
On the client, I did
svn cat http://.../broken/trunk/instrument/grabber/default.css | md5sum
which returned 2e9ef1ab231b053336d93d5c19151abb -- ie. the actual
checksum from the above error message.
On the server:
svn cat file:///data/subversion/repository-checksum-errors/trunk/instrument/grabber/default.css | md5sum
returned exactly the same checksum.
So where the heck is that expected checksum coming from? (I checked
.svn/entries, and there's no entry for default.css there.)
What are the checksums of the real files (use the `md5sum' utility to
find out), and do they match the checksums given above?
Not sure what you mean -- there's no default.css in my working copy, nor
in .svn/text-base, nor in .svn/tmp/text-base.
Greg
--
Greg Ward - software developer gward@mems-exchange.org
MEMS Exchange http://www.mems-exchange.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:09:24 2006