Blair Zajac <blair@orcaware.com> writes:
> I just got this message from a new svn revision 5254 on my Orca
> repository:
>
> % svn ci -F ../msg
> Sending INSTALL
> Sending configure.in
> Deleting packages/Digest-MD5-2.23
> Adding packages/Digest-MD5-2.24
> Sending packages/Digest-MD5-2.24/Changes
> Sending packages/Digest-MD5-2.24/MD5.pm
> Sending packages/Digest-MD5-2.24/MD5.xs
> Sending packages/Digest-MD5-2.24/t/files.t
> Transmitting file data .svn: Working copy text base is corrupt
> svn: Commit failed (details follow):
> svn: svn_wc_transmit_text_deltas: checksum mismatch for '/export/home1/blair/Code/Blair/Orca/orca1/packages/Digest-MD5-2.24/.svn/text-base/MD5.xs.svn-base':
> recorded checksum: c3f52008d0d1130807000000954ce37a
> actual checksum (hex): 6bff95ff70ba43a6c81e255c6510a865
> actual checksum (base64): a/+V/3C6Q6bIHiVcZRCoZQ==
>
> I'd like to help track this problem down.
>
> Next steps? What info do you guys need?
>
> This working copy was checked out on Jan 3, using a svn revision less
> then 4259.
There were a lot of checksum tweaks made after rev 4259; an older svn
could have written out the wrong data (I mean, that sucks, for legacy
working copies, but that bug is no longer present afaict).
One thing you could do is loop over each incarnation of that file (I
mean the file as it existed in every revision), and see if the
checksum "c3f52008d0d1130807000000954ce37a" matches any of them. If
it does, but the one it matches is not the same rev as the one in the
working copy right before you updated and got the checksum mismatch,
then we can be pretty sure what the scenario was.
(Just for future reference: you don't say what RA layer, or whether
5254 refers to client or server or both.)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 10 19:27:25 2003