You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Edward Ned Harvey <sv...@nedharvey.com> on 2011/01/06 00:07:22 UTC

problem with svnsync and repository locks...

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?


Re: problem with svnsync and repository locks...

Posted by Mark Phippard <ma...@gmail.com>.
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 <sv...@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/