See this thread:
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377143
Realistically today you need to add a pre-lock hook on the slave that
disallows the lock feature entirely.
Mark
On Wed, Jan 5, 2011 at 6:07 PM, Edward Ned Harvey <svn_at_nedharvey.com> wrote:
> I have a master server, and a slave server configured with pass-thru proxy.
> Off the top of my head, I believe they're both 1.6.12, but I'll double check
> if that is an important detail.
>
>
>
> A user at the slave site does "get lock" on a file. She gets the lock
> successfully.
>
> She makes a change, tries to commit. Commit fails because file is locked in
> repository. (What? Yeah.)
>
> She asked me for help, and I ensured she did NOT lock in one WC and then try
> to commit from another WC. All of these operations are happening in a
> single WC, using the slave server for the URL.
>
> She tries to unlock. Cannot unlock because file is not locked.
>
> She tries to lock. File is already locked.
>
>
>
> On another computer, I try to lock her file. Cannot lock - lock belongs to
> her. (I did not force steal the lock.)
>
> I try to unlock her file. Cannot unlock, file is not locked.
>
>
>
> I double-checked the revs of the master & slave. Both matching (we are not
> waiting for an in-progress svnsync to finish from master to slave.)
>
>
>
> The workaround was this: I made a connection directly to the master and
> forced the unlock. Then she was able to commit.
>
>
>
> Clearly, the presence of a repository lock is not properly communicated
> between master & slave. I double-checked my master server configuration,
> and ensured there is both a post-commit hook, and a post-revprop-change
> hook. Both of which have been working flawlessly for months.
>
>
>
> If necessary, I can reproduce this in a precisely documented way. But I
> didn't document it that thoroughly yet because I didn't think that's
> necessarily necessary.
>
>
>
> Is this simply a bug that was accidentally overlooked in the master/slave
> design? Is it a known issue?
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
Received on 2011-01-06 00:59:15 CET