Stein Roger Skafl¸tten wrote:
>>Except for a couple of details, what you describe is exactly what
>>we're working on.
>>
>>
>
>Sounds great! I hope the design note will be updated soon, because I find the published proposal/mailing list discussions to be quite different in detail from this one.
>
>
They're not, really, but we've focused more on the FS behaviour than on
the user interface.
>>>Please consider the update-and-lock model outlined below. In
>>>essence, this approach treats “lock” as a special kind of update and “unlock”
>>>as a special kind of commit.
>>>
>>>
>>>
>>I'm not sure why this would be useful. It only adds a shortcut to
>>existing functionalty.
>>
>>
>
>Under the "update-and-lock" proposal, updating and committing are actually required steps in the lock/unlock functions. Having to run two commands to lock or unlock resources don't seem robust, nor user friendly.
>
>
Well, under the current proposal, "commit" implies "unlock" by default,
so that part is covered. The only difference is the default behaviour of
"lock". I don't think we should force people to update when creating a
lock. Something like "lock --update" might be an option, but this is
syntactic sugar in th UI and I don't think we need to decide now.
>>>LEASES
>>>
>>>
>>Since we'll allow breaking of locks, the argument that "people forget
>>stuff" isn't strong enough, IMHO. Lock leases are good for
>>applications where a client can't break (or "steal") a lock. That's not the case here.
>>
>>
>
>If anyone was allowed to steal a lock, yes. But users should be able to steal locks only when authorized to do so. In my case, that would mean nobody except the administrator. If everyone can break locks to hearts content, chaos may follow.
>
>
Authorisation, or rather ACLs, are a separate issue. I tend to see locks
more as a method of communication between developers than a way to
constrain their behaviour. In the end, it all boils down to how much
effort people are prepared to put into working together effectively.
>Anyway, I think leasing is a "very-nice-to-have" feature, not a mandatory one.
>
There's one problem with leases that you've overlooked: if people tend
to forget to unlock stuff, they'll definitely forget to renew their lock
lease; or the'll simply revert to taking out week-long locks. You don't
gain a thing.
>Authorization w.r.t. to stealing locks, however, is!
>
>
I don't agree it's a must-have. After all, the effect on the lock owner
is the same as if her lock lease had expired. Sure, ACLs, once we have
them, will let you specify who can break locks. But following the
princilple I explained above, everyone can break locks by default.
--
Brane Èibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jun 17 03:31:33 2004