Re: svn commit: r1422042 - /subversion/trunk/subversion/libsvn_fs_fs/rep-cache.c

> URL: http://svn.apache.org/viewvc?rev=1422042&view=rev

> Log:
> Fix issue 4210, rep-cache not reseting SQLite statements on error.

I noticed the other day that WC DB code in many places fails to reset stmts on error, but that svn_sqlite__get_statement() automatically resets the stmt if it hasn't been reset since last used.  Does this tally with your understanding of what you just fixed in the rep-cache -- that is, it could be described as a functionally harmless coding style violation?

If so it would be good to say so in log msg & issue to indicate it doesn't need back-porting.

- Julian

> * subversion/libsvn_fs_fs/rep-cache.c
>   (svn_fs_fs__walk_rep_reference): Move a reset earlier, catch errors
>    and reset before returning.
>   (svn_fs_fs__get_rep_reference): Move a reset earlier.

> Modified: subversion/trunk/subversion/libsvn_fs_fs/rep-cache.c

>    /* Check global invariants. */
>    if (start == 0)
>      {
> -      svn_sqlite__stmt_t *stmt2;
>        svn_revnum_t max;
>
> -      SVN_ERR(svn_sqlite__get_statement(&stmt2, ffd->rep_cache_db,
> +      SVN_ERR(svn_sqlite__get_statement(&stmt, ffd->rep_cache_db,
>                                          STMT_GET_MAX_REV));
> -      SVN_ERR(svn_sqlite__step(&have_row, stmt2));
> -      max = svn_sqlite__column_revnum(stmt2, 0);
> +      SVN_ERR(svn_sqlite__step(&have_row, stmt));
> +      max = svn_sqlite__column_revnum(stmt, 0);
> +      SVN_ERR(svn_sqlite__reset(stmt));
>        if (SVN_IS_VALID_REVNUM(max))  /* The rep-cache could be empty. */
>          SVN_ERR(svn_fs_fs__revision_exists(max, fs, iterpool));
> -      SVN_ERR(svn_sqlite__reset(stmt2));
[...]
Received on 2012-12-14 20:59:30 CET