Greg Stein wrote on Sun, Mar 25, 2012 at 14:52:41 -0400:
> On Sun, Mar 25, 2012 at 13:35, <danielsh_at_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
> > +<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 this summary of issue #4129 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.
Received on 2012-03-26 14:00:30 CEST