Change Details

When ingesting the asf mirror, if some errors occur during the loading, the process stops. That's ok. Now, it will create an occurrence targeting a revision which holds the svn revision. When starting again the loading of the repository, it fails saying that the history has been altered. What it does is retrieved the last svn revision known, export it locally and compute the hash tree. And then compare that hash tree with the corresponding hash tree (stored in the swh revision). Matching those here fails, thus the error message. The asf mirror in question did not change so it's a bug. This is symptomatic of a divergence in the directory hash tree computation. But now, i need to investigate it further.

When ingesting the asf mirror, if some error occurs during the loading, the process stops. That's expected and dealt with. At the moment, this will create an occurrence targeting a revision which holds the svn revision and update the origin_visit to set its status accordingly. When starting again the loading of the repository, as it is already know, it will fetch the last known revision (and its corresponding svn revision). Svn export at that svn revision on the disk and then compute its hash tree and then the revision hash. Compare that revision hash with the one already stored in the db. If it matches, it continues to load from that point on. If it mismatches, it logs an error message about altered history and stops. This is what currently happens. BUT: The asf mirror in question did not change. It's a bug. This is symptomatic of a divergence in the directory hash tree computation. This is about investigating further this tree divergence.

When ingesting the asf mirror, if some errors occurs during the loading, the process stops. That's ok. Nowexpected and dealt with. At the moment, itthis will create an occurrence targeting a revision which holds the svn revision and update the origin_visit to set its status accordingly. When starting again the loading of the repository, it fails saying thatas it is already know, it will fetch the history has been alteredlast known revision (and its corresponding svn revision). What it does is retrieved the lasSvn export at that svn revision known, export it locallyon the disk and then compute its hash tree and compute the hash treethen the revision hash. And then cCompare that hash treerevision hash with the corresponding hash tree (stored in the swh revision)one already stored in the db. If it matches, it continues to load from that point on. Matching those here failsIf it mismatches, thus theit logs an error messagee about altered history and stops. This is what currently happens. BUT: The asf mirror in question did not change so i. It's a bug. This is symptomatic of a divergence in the directory hash tree computation. But now, i need toThis is about investigate it furthering further this tree divergence.