On 1/9/14, 2:48 PM, kmra...@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.