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!
