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 <s...@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/
