After my commits of revisions 1787 and 1788, some people may run into
the same problem Ben Collins-Sussman experienced this morning:
> Btw, karl, I tried to update this morning, and got a bogus checksum
> error on my svn_diff.h text-base. I have no idea what's up. The file
> was perfect, I looked at it. Maybe it had an older checksum from an
> older generation of the code? Maybe APR changed its checksum
> algorithm recently? It was puzzling, so I just shrugged and did a
> fresh checkout with my existing binary.
Don't worry, it doesn't mean your working copy is corrupt. It's just
a problem bootstrapping [some] old working copies to the final version
of the checksum code.
If it happens to you, you can either check out a whole new working
copy like Ben did, or (if you're feeling squirrely) edit the relevant
.svn/entries files to simply remove the offending checksums. Either
way is fine.
Here's the cause:
The first checksum-related change was rev 1683; it caused a new
checksum to be stored for a file at commit time. So people running
binaries since 1683 would have a checksum for any file they had
committed from that working copy.
However, not until revisions 1787/1788 did *updates* correctly reset
the checksum on changed files. So if you committed a file, and then
that file later received updates, its checksum would become obsolete.
That didn't matter until rev 1787/1788, because checksums weren't yet
compared, they were only stored :-). Now that they're both stored and
compared, some of these files may suddenly start causing you a
Sorry for the inconvenience, I should have seen this coming.
Why is it safe to simply remove a checksum from the entry? Because
for backwards compatibility (and other reasons), an absent checksum is
not an error, it simply causes the checksum comparison to succeed
unconditionally. That file will eventually get a checksum when it's
committed or updated.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Apr 26 21:17:40 2002