On 1/9/14, 2:48 PM, kmradke_at_rockwellcollins.com wrote:
> I've observed 3 instances of similar errors when using the 1.8.5 svnadmin
> verify on 3 different old repositories. (the hundreds of other repos on
> this server verified in 1.8.5 without problems.)
>
> svnadmin: E160004: r97's root node's predecessor is r90 but should be r96
> svnadmin: E160004: r502's root node's predecessor is r483 but should be r501
> svnadmin: E160004: r22033's root node's predecessor is r22031 but should be r22032
>
> All 3 of these repositories verify without errors using 1.7.5. All 3 of the
> revisions are from different months in 2009, when I assume the server was
> running 1.6.something. The repositories were "upgraded", but not a full
> dump/load between major version upgrades.
This is documented in the 1.8. release notes here:
https://subversion.apache.org/docs/release-notes/1.8.html#verify-issue4129
> Also, on a slightly related note, why does the new svnadmin verify
> medatadata portion not always start at r0 or even show consecutive
> revision numbers on repositories with large numbers of revisions?
That's verifying the representation cache db. r0 will never have any entry
since r0 is always an empty revision with no file contents (and thus no
represenations). It will never have an entry for every revision. There are a
couple reasons why a given revision might not have an entry:
* rep-cache wasn't enabled when a revision was committed (most notably upgrade
repos that existed before 1.6 when this feature was added and that haven't gone
through a dump/load cycle since).
* revision didn't add any new representations when it was committed. Copies
with history (e.g. branching/tags) will use the representation from the source
for the files. If a representation has already existed for a given file
content and is found in the rep-cache.db then that representation will be
reused for the file contents in the new revision.
Received on 2014-01-10 00:48:51 CET