STATUS

      * * * * * * * * * * * * * * * * * * * * * * * * * * * *
      *                                                     *
      *  THIS RELEASE STREAM IS OPEN TO BUG FIXES.          *
      *                                                     *
      * * * * * * * * * * * * * * * * * * * * * * * * * * * *

This file tracks the status of releases in the 1.7.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.7.0:

Candidate changes:
==================

 * r1146131 and followups
   Add svn_fs_verify() and implement rep-cache verification in FSFS using it.
   Branch:
     1.7.x-fs-verify
   Justification:
     Would be nice to extend verify already in 1.7.x.
   Notes:
     This does not include progress reporting, since that is nominated
     separately.
   Votes:
     +0: danielsh
     +0: gstein (progress would be nice)

 * fs-progress branch
   Notes:
     Depends on the r1146131 group (1.7.x-fs-verify).
   Branch:
     fs-progress
   Justification:
     Provide feedback during 'svnadmin verify'.
     Avoid an API change in 1.8.
   Notes:
     If this proposal passes, the docstrings @since would have to be fixed
     in a new commit.
   Votes:
     +0: danielsh

 * r1147882
   Convert (pre-lock hook)-specified lock tokens to UTF-8.
   Justification:
     (zhakov, please fill in)
   Votes:
     -0: danielsh (pending clarification whether it's a mod_dav_svn bug,
                   libsvn_repos/libsvn_fs token validation bug, or both;
                   see dev@)

 * r1148424
   Resolve issue 3963, 'svn update -r{R>HEAD}' hangs client over ra_svn.
   Justification:
     Subversion and svnserve shouldn't hang waiting for IO that will
     never come when a user passes a revision that hasn't been committed
     yet.
   Votes:
     +0.5: rhuijben (I think this patch is ok as it resolves the problem
                     and fixes the error reporting. But I like to see some
                     confirmation from an ra_svn developer that this is the
                     right way to fix this problem)

 * r1148566
   Fix a memory leak in svn merge.
   Justification:
     Memory leaks are bad.
   Votes:
     -0: rhuijben (r1148588 fixes the immediate problems and this code can use
                   a bit more cleanup before backporting. See also the
                   dev@s.a.o thread for gstein's concerns)
     +1: stsp (r1148588 alone does *not* fix the leak)

 * r1148588
   Use a subpool for each log item in ra_serf instead of allocating all the
   structures in the main parser pool and store a variable in the right pool.
   Justification:
     Reduces memory consumption during log processing (E.g. svn log, svn merge,
     svn mergeinfo), and provides a proper scratch pool to receivers for
     further memory usage reduction.
   Votes:
     +1: rhuijben, stsp

Approved changes:
=================