On Tue, Mar 6, 2018 at 5:21 PM, NOCERA, ANDY <an2...@att.com> wrote: > John, > > Good feedback. > > Svnadmin 1.9 verify is showing the error also. I did a dump and load and it > resolved that repo. Having reviewed my repos, it looks like around 30% > have this issue. Not sure what we could have done wrong to cause it. A > real simple repo is mine and has only a few commits shows the error. Is > there a correction method quicker than a dump and load? >
Nice, great that dump+load fixes it. I don't think there is a quicker method. It might be worth investigating why this happened to begin with. But I don't really know where to start. One hypothesis is that this corruption is already lingering there for years (until 1.9 it wouldn't have been noticed) ... perhaps something outside of SVN manipulated the rev files years ago? Or perhaps there was a bug once in SVN that caused this to happen (but the corruption remained benign / unnoticed, until the stricter validation by 1.9). It's also possible that the stricter validation by 1.9 contains a bug, and is too strict for some cases (though in that case I would have expected more reports on this list). Maybe you can make a more accurate hypothesis by investigating exactly what the "Malformed node revision ID string"s looks like. Actually, danielsh just improved that error message a few days ago, by adding the actual data to the error message: http://svn.apache.org/viewvc?view=revision&revision=1825846 So if you can build svn from source you might be able to perform a build from the latest svn trunk, and run 'svnadmin verify' to get the more verbose error message (be careful not to use your trunk svn build on production data without creating a backup of course). Or alternatively you can try taking a look into the rev files yourself, to find the "malformed node revision ID". -- Johan
