Greg Stein wrote on Sun, Mar 25, 2012 at 14:52:41 -0400: > On Sun, Mar 25, 2012 at 13:35, <danie...@apache.org> wrote: > >... > > +++ subversion/site/publish/docs/release-notes/1.8.html Sun Mar 25 17:35:32 > > 2012 > >... > > +was not.) As of 1.7.1 Subversion <a > > +href="http://svn.apache.org/viewvc/subversion/branches/1.6.x/subversion/libsvn_fs_fs/fs_fs.c?rev=1303070&r1=1303069&r2=1303070&view=diff"; > > +>prevents</a> new instances of the corruption, but > > +only as of 1.8.0 does 'svnadmin verify' <a > > + > > href="http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/tree.c?r1=1304656&r2=1304655&pathrev=1304656"; > > +>detect</a> instances of that corruption in the history of a > > repository.</p> > > Do we really want to link people to the *code* from our release notes? > The code doesn't seem very helpful for users. >
I guess we could drop these links, either replace them by the revnums or delete them. > > +<p>The fix to these issues is simple: perform a dump/load cycle. (As > > usual, > > +svnsync can be used instead of dump/load.) The cycle can be done with any > > version > > +of Subversion, and after the cycle the repository should be served > > exclusively by > > +Subversion 1.7.1 and newer (or 1.7.5 and newer) to prevent further > > instances of the > > +bug from entering the repository.</p> > > Huh? Is it 1.7.1, or 1.7.5? > 1.7.1 detects the problem and rejects commits that have it. (It detects just pred-count mismatches on the root noderev, but I think that suffices.) 1.7.5 fixes the cause of the problem. > > +<p>See <a href="../issue4129">this summary of issue #4129</a> for more > > information > > Should that link have a .txt or .html on the end? > No. The file has .txt, but by linking to it this way the links will keep working when we convert it to .html. > Cheers, > -g
