Mark Phippard wrote on Fri, Jul 15, 2011 at 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.
If svnsync presents the lock token that's present on the master, and
hopefully the slave checks locks against the master during commit, the
commit is going to work isn't it?
Point is: using 'svnadmin lock', despite creating locks on the slave's
FS, doesn't change the fact that those locks are *cached* locks, they
aren't binding/normative in any way.
Received on 2011-07-15 18:17:48 CEST