On Aug 15, 2007, at 14:56, Steve Suehs wrote:
> I've seen something strange that appears to be wc corruption.
> Every once in a while we find a wc that thinks it is up-to-date but a
> given file is different than its copy in a freshly-checked-out wc.
> We have not been able to isolate the actions that lead up to the
> condition... yet. Usually this occurs because the developer does
> something clever with find, sed/awk etc, which changes file copies in
> the .svn directories.
Oh yes. Do not muck with the files in the .svn directory! I believe
if the file in the text-base directory of the .svn directory has the
same mtime as the corresponding real file, then the checksums aren't
even checked, or something like that. And if the sed/awk completed in
< 1 second this is what would happen.
> I have noticed a pattern involving a revert and merging may come into
> play as well. I'm still trying to nail it down. It is not consistent
> enough to be readily reproducible. (Intermittent bugs are fun that
> way...and it may indeed turn out to be pebcakb.) I notice that the
> checksum in the wc appears to be the same as the checksum in the fresh
> copy, though the files are different, so the checksum is cached or not
> recalced.
>
> Is there a sanity check command to have the subversion client re-calc
> checksums or to do a paranoid check against the repository? Or an
> alternative idea would be great, too.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Aug 15 22:20:06 2007