On 03.07.2015 14:05, Ivan Zhakov wrote:
> There are several changes merged to 1.9.x branch since 1.9.0-rc2:
>  * r1686554, r1686557, r1686239, r1686541, r1686543, r1686802
>    Fix 'svnadmin hotcopy' for read-only FSFS repositories
>    Justification:
>      Format 7 repositories could not be hotcopied without write access to
>      the source repo - which is a regression vs. older formats.  Because
>      the new test case also uncovered another regression with hotcopying
>      the rep-cache.db from r/o repos.
>
>  * r1682714, r1682854, r1683126, r1683135, r1683290
>    Fix segfaults in FSX's directory processing code.
>    Justification:
>      Despite its experimental state, FSX shall not segfault the server.
>
>  * r1686478, r1686888, r1686984
>    Make 'blame -g' work with old clients against new servers.
>    Justification:
>      Without this patch, old clients will "lose track" of what changes
>      happened in -g mode and produce wrong / worse blames than against
>      old servers.
>      The output of 'blame -g' is only an approximation.  However, the
>      new server would cause much worse results in old clients especially
>      in simple cases where lines of development are kept in close sync.
>
>  * r1685085
>    Install svnbench as part of 'make install'.
>    Justification:
>      svnbench moved from  tools/ to subversion/ so it should be installed
>      by default.
>
>  * r1683378
>    Prevent a possible FSFS repository corruption with power or network disk
>    failures during 'svnadmin pack'.
>    Justification:
>      Repository corruption/data loss.
>
>  * r1683303
>    Resolve a race condition in some test suite cleanup code.
>    Justification:
>      Without this patch running the testsuite on bdb x svnserve consistently
>      fails on at least some Windows test systems. bdb x serf sometimes
>      triggers the same problem, but in far less cases.
>      .
>      This specific test -unlike other tests- cleans up its own environment a
>      few times to retry some scenarios on the same paths.
>
>  * r1684325, r1684344
>    Fix an unintended doubling of error messages in 'svnadmin verify'
>    without the --keep-going flag.
>    Justification:
>      Fixes a bug that was introduced in r1683311, which was
>      already merged to 1.9.x.
>
>  * r1684412
>    Make JavaHL native code compile with a C++11 compiler.
>    Justification:
>      The upcoming MSVC14, part of Visual Studio 2015,
>      supports user-defined literals, which means that
>      trying to build JavaHL with VS2015 will fail.
>
>  * r1684077
>    Detect invalid svndiff data earlier.
>    Justification:
>      Do not waste memory on invalid user or server input.
>
>  * r1684322
>    Fix a minor omission in JavaHL's VersionExtended class:
>    the dispose() and finalize() methods were missing.
>    Justification:
>      Without the dispose() method, the user of the VersionExtended
>      class cannot avoid a memory leak in native memory.
>
>  * r1684034
>    Fix prop_tests.py#42 test failures with non-US default locale on
>    Windows [1].
>    Justification:
>      Tests should not fail.
>
>  * r1683311
>    Make error reporting from svn_repos_verify_fs3 consistent
>    with behaviour of svn_repos_verify_fs2 in 1.8.x.
>    Justification:
>      Errors from the FS implementation are squashed even in normal
>      mode without --keep-going. See: http://s.apache.org/j9Z
>
>  * r1683387
>    Fix abort() in svn-status handler on platforms that doesn't support C99
>    format specifiers for strftime(): %F and %z are new in C99 and C89
>    compiler/runtime doesn't support them.
>    Justification:
>      Server-side crash in new small feature. Simple fix.
>
>  * r1683071
>    Document the meaning of "XFAIL" for users building from source.
>    Justification:
>      Answers a FAQ.
>
> These commits contain public API changes and the community guide
> states that such changes should be considered as potentially
> destabilizing.
>
> So maybe it's time to release RC3 and restart the soak period?

I was going to get the tarballs rolled during the week-end, yes. I don't
think this needs another soak restart, though; just an extension,
perhaps 2 weeks since we're close to the end of the current soak? I
think we've done a pretty thorough job of testing 1.9.0 by now.

-- Brane

Reply via email to