* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * THIS RELEASE STREAM IS OPEN TO BUG FIXES. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * This file tracks the status of releases in the 1.8.x line. See http://subversion.apache.org/docs/community-guide/releasing.html#release-stabilization for details on how release lines and voting work, what kinds of bugs can delay a release, etc. Status of 1.8.13: Candidate changes: ================== * r1536854 Make 'svnadmin verify' detect inconsistencies that will prevent loading dump files. Justification: Some users rely on dump files as a means of repository backup. Without this patch, there is no way except of 'svnadmin load' to know that these dump files will load at all. With this patch, a successful verify run should guarantee loadable dump files. Branch: ^/subversion/branches/1.8.x-r1536854 Votes: +1: stefan2, breser -0: julianfoad (test is missing from branch -- how do we know it works?) * r1654932, r1654933, r1654934, r1654937 Fix issue #4554, "0 file length reported in FSFS". Justification: This causes 'svnadmin dump' to create corrupted output that fails to load and we provide no way to detect that problem other than loading the respective dump. We also want to prevent further instances of that issue to be added to the repository. Notes: r1561419 has been removed from this change set and proposed for a separate backport because it is not a necessary part of the #4554 fix. Branch: ^/subversion/branches/1.8.x-issue4554 Votes: +1: stefan2 +0: rhuijben (patch looks sane, but hard to oversee consequences) +0: danielsh (hard to review all potential causes of expanded_size==0 in 7*3*2 cases (1.1…1.8) × (file/dir/prop rep) × (plain/delta)) * r1666965, r1667120 Reduce 'the lag' of the first svn log results over mod_dav. Justification: A slow svn log makes users call Subversion slow. This fixes the perceived performance problem by no longer optimizing just for obtaining all the results fast, but also for obtaining the first result fast. . Just the perceived slowness of common svn log operations might make users switch to a DVCS or implement a client side cache, while this slowness is just a buffering to make the total set of results come in faster. But I don't think there are that many users that really wait for all results of . $ svn log -q ^/subversion/trunk . This currently takes > 10 seconds before the first result using the EU mirror for me. With --limit 1 (best comparison with post-patch) that would be 0.2 seconds. Votes: +1: rhuijben, philip (After it has been approved for 1.9) -0.5: ivan (It's not security or bug fix. The change itself a little bit controversial for me, so it's better to release it as part of Subversion 1.9.0) Veto-blocked changes: ===================== Approved changes: =================