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?
