[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

problem with svnsync and repository locks...

From: Edward Ned Harvey <svn_at_nedharvey.com>
Date: Wed, 5 Jan 2011 18:08:35 -0500

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?

 
Received on 2011-01-06 08:52:15 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.