On Tue, Mar 6, 2018 at 5:21 PM, NOCERA, ANDY <an2...@att.com> wrote:
> 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
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:
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".