On Oct 12, 2007, at 11:03 AM, Justin Erenkrantz wrote:
> The LOCK and UNLOCK requests would get sent to the master - but lock
> discovery would fail as the slaves wouldn't know about the locks.
> Hence, the user would need to issue a force unlock to break it.
> Locking would still work - it just would never get reported properly
> as having a lock held via the APIs.
The purpose of lock is "to prevent two people changing the same file
concurrently, at least without conscious decision and extraordinary
steps like breaking the lock." That is, it's not just that users
want their commits protected from overwriting (though they want that,
too), but rather that they want to be prevented even from beginning
the work which would eventually collide.
It sounds to me, therefore, as if "[locking] would never get reported
properly" may be restated as "locking would be broken." They would,
I think you're saying, eventually learn that they both modified the
same file (at someone's commit), but the "modify concurrently" would
already be done.
-==-
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:14:20 2007