Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of metabolism@nedharvey.com
 designates 66.46.182.58 as permitted sender)
From: Edward Ned Harvey <svn@nedharvey.com>
To: <dev@subversion.apache.org>
Subject: problem with svnsync and repository locks...
Date: Wed, 5 Jan 2011 18:08:35 -0500
Message-ID: <000501cbad2d$7e453730$7acfa590$@nedharvey.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0006_01CBAD03.956F2F30"
Thread-Index: AcutLXiz+mco2GJqRNOlUhzYCYwj3w==
Content-Language: en-us

------=_NextPart_000_0006_01CBAD03.956F2F30
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

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?

 
------=_NextPart_000_0006_01CBAD03.956F2F30--