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

Re: [PATCH] Issue 3942 - Provide new subcommand on svnadmin to create a lock

From: Mark Phippard <markphip_at_gmail.com>
Date: Fri, 15 Jul 2011 12:02:53 -0400

On Fri, Jul 15, 2011 at 11:59 AM, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> Mark Phippard wrote on Fri, Jul 15, 2011 at 11:55:07 -0400:
>> > To keep the information on this thread I quote a bit of information that was just added to this issue:
>> >
>> > ------- Additional comments from jmountifield_at_tigris.org Fri Jul 15 07:01:25 -0700 2011 -------
>> >
>> > Replicating the locks to the slave server, even with the right lock token value,
>> > still leaves us with some issues in the master/slave configuration. The
>> > following is based on local testing with svn, version 1.6.12 (r955767).
>> >
>> > Once a slave repository has locks present you cannot keep that slave up to date.
>> > This is true with both `svnsync sync` and `svnadmin load`.
>> >
>> > With svnsync the reasons are somewhat obvious. The process looks like a normal
>> > commit, and commits are blocked by locks. So, unless there's some way to change
>> > the locking behaviour for svnsync specifically, I can't see a workaround here.
>> This is good information ... thanks.
>> As long as we call post-unlock before post-commit it remains possible
>> for a replica to have the locks removed before svnsync tries to sync
>> the commit ... right?
> But that way you can't make the post-unlock script background itself
> before it contacts the slaves...

The solution we use at CollabNet implements a message-queue type
system. So post-unlock could queue up a command for all the replicas
and then post-commit would be queued after it. All replicas would
process the commands in sequence.

Of course it occurs to me that anyone that commits with the
--keep-locks option would still break things.

Mark Phippard
Received on 2011-07-15 18:03:26 CEST

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