[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [Issue 533] New - implement reserved checkouts

From: Bill Tutt <rassilon_at_lyra.org>
Date: 2002-08-02 20:40:16 CEST

> From: Karl Fogel [mailto:kfogel@newton.ch.collab.net]
> "Bill Tutt" <rassilon@lyra.org> writes:
> > If it's not pointless then they can branch it. :)
> :-)

[Rearranged for clarity]
> Maybe I'm confused about terminology? I thought:
> - "advisory lock": a lock that can be overridden or stolen.

When I say advisory lock I mean: A shareable write lock.

Multiple people can hold one of these, and anyone of those holders can
commit changes.

With diff-able, and merge-able files, this works out just fine. With
files that don't work that way life is a little more annoying with just
an advisory lock. When people take out locks on these kinds of files,
they want to know now as opposed to when they try and commit that
something bogus is happening. An advisory lock can sometimes be to easy
to ignore.

> - "firm lock": only the locker, or an admin, can undo this.

Firm lock: Exclusive write lock.

Which does mean that only the locker, or an admin can undo the lock.

> What I'm getting at is:
> > > If they're both aware that they're doing it, but they keep doing
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> That is, if there is an advisory lock, telling them that they're both
> modifying the same file, and they persist, they must be persisting for
> reason. And those who don't have a reason to persist can just make a
> branch at that point.
> All I'm saying is, no reason to have two kinds of locks here. One
> kind of lock is fine, and it's okay for it to be stealable
> (overrideable, whatever you want to call it). Because if someone
> overrides, then they chose that course consciously.
> And I'm advocating that we have only advisory locks.

Yes, I understand the desire to have only one kind of locking system but
user behaviors go and get in our way enjoy complicating our lives. As I
said above, advisory locks can be easier for users who aren't paying
attention to what they're doing to accidentally ignore. It's impossible
to ignore a firm lock.

Now it may be that not everybody wants to have firm locks on those kinds
of files. That's ok by me, but it seems to me that there is going to be
a > 5% of our user base that would like to have firm locks supported on
those kinds of files.


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Aug 2 20:40:48 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.