On Fri, 2002-08-02 at 18:33, Jim Blandy wrote:
>
> I'd like to hear more about people's real-life situations, more at the
> ``project manager looking for good working procedures'' level, and
> less at the ``Subversion implementor'' level. Karl's post about how
> RCS locks behave with real people going on vacation is at the right
> level. Bill Tutt hinted at more restrictive applications --- it would
> be great to hear the whole story about those.
I'm probably a little short on the real world experience compared to
most people here, but here is what keeps bugging me about this
discussion:
Anyone that is discussing hard locks (where only an admin or the user
with the lock can release it) in the same breath says there needs to be
a way for a user to override this and check in code that someone else
has locked. So it really seems to me that all locks would be advisory
in nature, and what we're really discussing is how many extra command
line options it takes to override a lock. It seems that any sort of
locking should require some sort of --force option in order to break
someone else's lock, even if it is just advisory in nature, just so a
user is forced to acknowledge that "I am aware that someone else has an
interest in me not changing this file, but my interest in changing it
overrides that". I guess I just find it hard to see how hard locks that
can be overridden are any different than advisory locks, or how they do
anything to ease the mind of someone that thinks hard locks are a good
thing in the first place. Whatever sense of security they get out of
this scheme seems somewhat false, and I'm not sure how much Subversion
should contribute to this false sense of security.
Woogie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Aug 3 17:42:13 2002