On Fri, Jul 15, 2011 at 11:59 AM, Daniel Shahaf <d...@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 jmountifi...@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. -- Thanks Mark Phippard http://markphip.blogspot.com/
