I have two fossil repositories (the "local" one and the "remote" one) and I get the following error when I try to pull:
"content does not mach sha1 hash"
So, first of all, I would like to establish if one or both repositories are corrupted.
Are there specific commands to check the integrity of a fossil repository?
I tried
fossil info
fossil rebuild
but none of them seems to be able to detect (nor fix) inconsistencies in my repositories.
I use fossil version 1.18 (on both machines).
Suggestions?
Thanks in advances.
Marco
_______________________________________________
fossil-users mailing list
fossil...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Hello,
I have two fossil repositories (the "local" one and the "remote" one) and I get the following error when I try to pull:
"content does not mach sha1 hash"
So, first of all, I would like to establish if one or both repositories are corrupted.
Are there specific commands to check the integrity of a fossil repository?
I tried
fossil info
fossil rebuild
but none of them seems to be able to detect (nor fix) inconsistencies in my repositories.
I use fossil version 1.18 (on both machines).
Suggestions?
Thanks in advances.
Marco
_______________________________________________
fossil-users mailing list
fossil...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
I run test-integrity and I found that both repositories are corrupted.
One says:
fossil: checksum mismatch on blob rid=58:
da39a3ee5e6b4b0d3255bfef95601890afd80709 vs
01f57728b3a5d55520becb489146d0a7f42f9638
The other says:
skip phantom 177 ccc986b41c2a37fb86a8267d2dd0ac0b17e12bc9
fossil: checksum mismatch on blob rid=178:
da39a3ee5e6b4b0d3255bfef95601890afd80709 vs
15e01a5726c26fe931d4b833215defd17ec9b3ae
Now what I am supposed to do to try to solve this situation?
Can I hope to recover from this inconsistency?
Thanks again.
M.
2011/8/9 Richard Hipp <d...@sqlite.org>:
BTW, these repositories are quite small (~120K).
If you think that they can be useful for debugging, I can send them to you.
Thank you for your support,
Marco
2011/8/9 Marco Maggesi <marco....@gmail.com>:
Thank you for your quick answer.
I run test-integrity and I found that both repositories are corrupted.
One says:
fossil: checksum mismatch on blob rid=58:
da39a3ee5e6b4b0d3255bfef95601890afd80709 vs
01f57728b3a5d55520becb489146d0a7f42f9638
> da39a3ee5e6b4b0d3255bfef95601890afd80709 is the hash for a zero-length
> object. Something is clearly messed up.
As a general rule of thumb, whenever mysteriously zero-length files crop
up, the first thing I check is whether anything's run out of disk space
at any point...
...shortage of disk space can result in files being creatable (taking up
already-allocated space in inode tables and directory entries) but then
not being writable (leading to zero-length files).
ABS
--
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/