On Oct 12, 2007 11:45 AM, Jack Repenning <jrepenning@collab.net> wrote:
> This appears to open a timing window ... or maybe better stated, "to
> not quite entirely close the timing window." During the time after
> the lock has been applied at the master repo, but the rsync machine
> is revving up, the client may attempt to lock, grant it because the
> rsync's lagging, and then ... what?
No. The LOCK command will always fail as it goes to the master
machine. The slave doesn't get involved in LOCK or UNLOCK as we are
only supporting a single 'master' in this configuration. So, it's not
possible for us to give the lock to two people at once - the issue
here is what visibility does the slave have into the lock database so
that its clients can determine whether there is a lock or not.
> Maybe I'm not clear on the protocol here. I think I'm about to
> reverse myself. There isn't any "svn gee-i-wonder-if-i-could-lock-
> this-file" command. The "svn status" command shows lockedness, and
> these questions of timeliness matter to that, but the actual "lock"
> command, you say, does indeed propagate to the master. So "lock"
> still happens right, right?
Yes.
> Someone who does this:
> 1. svn state
> 2. "cool, not locked"
> 3. svn lock
>
> ... is just asking for trouble, anyway, lest someone else take out a
> lock at point 2.5.
Yes - there is *always* a race condition here. The window is just a
bit wider if we have to propogate the lock database to the slaves
somehow.
(The same window also exists for commits; but in the real world(TM),
writes are *far* *far* *far* less frequent then reads.)
> So aren't we really talking about the difference between an "svn
> lock" command that fails locally or remotely?
Eh, sort of - but I'm not quite clear on your question. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 12 20:51:03 2007