Stefan Sperling wrote on Mon, Mar 06, 2017 at 17:22:14 +0100:
> On Mon, Mar 06, 2017 at 04:06:44PM +0000, Daniel Shahaf wrote:
> > I can reproduce this using the FS API only (without the contrib/ script):
>
> Hmm, looks like the contrib script is using the API wrong.
> Check out what 'svnadmin unlock' does:
> [[[
> /* Open the repos/FS, and associate an access context containing
> USERNAME. */
> SVN_ERR(open_repos(&repos, opt_state->repository_path, opt_state, pool));
> fs = svn_repos_fs(repos);
> SVN_ERR(svn_fs_create_access(&access, username, pool));
> SVN_ERR(svn_fs_set_access(fs, access));
>
> SVN_ERR(svn_utf_cstring_to_utf8(&lock_path_utf8, lock_path, pool));
> if (opt_state->bypass_hooks)
> SVN_ERR(svn_fs_unlock(fs, lock_path_utf8, lock_token,
> FALSE, pool));
> else
> SVN_ERR(svn_repos_fs_unlock(repos, lock_path_utf8, lock_token,
> FALSE, pool));
> ]]]
>
> The script should probably be doing something like this, too.
I don't think so. The documentation of svn_fs_unlock() points to
the documentation of svn_fs_unlock_many(), which states:
* If @a fs has no username associated with it, yield an
* #SVN_ERR_FS_NO_USER (E160034) unless @a break_lock is specified.
The reproductions pass break_lock=True, so shouldn't get that error.
Cheers,
Daniel
> Doug, I believe filing a bug is entirely appropriate here. Thanks!
Received on 2017-03-06 17:37:07 CET