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
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 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.
> Cheers,
> -g
Received on 2012-03-26 14:00:30 CEST