You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by ep...@google.com on 2008/04/29 00:15:08 UTC
Re: svn commit: r30827 - in trunk/subversion: svnserve tests/cmdline
epg@tigris.org writes:
> --- trunk/subversion/svnserve/serve.c Mon Apr 28 16:23:31 2008 (r30826)
> +++ trunk/subversion/svnserve/serve.c Mon Apr 28 17:13:11 2008 (r30827)
> @@ -1082,13 +1155,11 @@ static svn_error_t *unlock_paths(apr_arr
> iterpool);
>
> /* The lock may have become defunct after the commit, so ignore such
> - errors.
> -
> - ### If we ever write a logging facility for svnserve, this
> - would be a good place to log an error before clearing
> - it. */
> - svn_error_clear(svn_repos_fs_unlock(sb->repos, full_path, token,
> - FALSE, pool));
> + errors. */
> + err = svn_repos_fs_unlock(sb->repos, full_path, token,
> + FALSE, pool);
> + log_server_error(err, sb, conn, iterpool);
> + svn_error_clear(err);
Why don't we use iterpool in that svn_repos_fs_unlock call? I
left it using pool because I wasn't sure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r30827 - in trunk/subversion: svnserve tests/cmdline
Posted by ep...@google.com.
Karl Fogel <kf...@red-bean.com> writes:
> epg@google.com writes:
> >> /* The lock may have become defunct after the commit, so ignore such
> >> - errors.
> >> -
> >> - ### If we ever write a logging facility for svnserve, this
> >> - would be a good place to log an error before clearing
> >> - it. */
> >> - svn_error_clear(svn_repos_fs_unlock(sb->repos, full_path, token,
> >> - FALSE, pool));
> >> + errors. */
> >> + err = svn_repos_fs_unlock(sb->repos, full_path, token,
> >> + FALSE, pool);
> >> + log_server_error(err, sb, conn, iterpool);
> >> + svn_error_clear(err);
> >
> > Why don't we use iterpool in that svn_repos_fs_unlock call? I
> > left it using pool because I wasn't sure.
>
> Looks to me like iterpool would be fine. The code to
> svn_repos_fs_unlock() just uses the pool for hook-running and unlocking;
> everything stays within the scope of that call, so there shouldn't be
> any lifetime issues.
r30841, thanks
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn commit: r30827 - in trunk/subversion: svnserve tests/cmdline
Posted by Karl Fogel <kf...@red-bean.com>.
epg@google.com writes:
>> /* The lock may have become defunct after the commit, so ignore such
>> - errors.
>> -
>> - ### If we ever write a logging facility for svnserve, this
>> - would be a good place to log an error before clearing
>> - it. */
>> - svn_error_clear(svn_repos_fs_unlock(sb->repos, full_path, token,
>> - FALSE, pool));
>> + errors. */
>> + err = svn_repos_fs_unlock(sb->repos, full_path, token,
>> + FALSE, pool);
>> + log_server_error(err, sb, conn, iterpool);
>> + svn_error_clear(err);
>
> Why don't we use iterpool in that svn_repos_fs_unlock call? I
> left it using pool because I wasn't sure.
Looks to me like iterpool would be fine. The code to
svn_repos_fs_unlock() just uses the pool for hook-running and unlocking;
everything stays within the scope of that call, so there shouldn't be
any lifetime issues.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org