On Oct 12, 2007, at 11:27 AM, Justin Erenkrantz wrote:
> Actually, thinking about it some more - I think we could try to be
> cute - have the post-lock and post-unlock hooks trigger a push to the
> slaves of the lock database. This way the slaves would indeed have
> the correct locking information stored locally.
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?
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?
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.
So aren't we really talking about the difference between an "svn
lock" command that fails locally or remotely?
-==-
Jack Repenning
Chief Technology Officer
CollabNet, Inc.
8000 Marina Boulevard, Suite 600
Brisbane, California 94005
office: +1 650.228.2562
mobile: +1 408.835.8090
raindance: +1 877.326.2337, x844.7461
aim: jackrepenning
skype: jrepenning
---------------------------------------------------------------------
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:45:36 2007