Justin Erenkrantz wrote:
> --On Tuesday, April 12, 2005 1:16 AM -0400 Greg Hudson <ghudson@MIT.EDU>
> wrote:
>> I second Julian's "why?". If someone has endeavored to override the
>> client's read-only bit on the file, there is no advantage to
>> antagonizing them further by demanding they get a lock before committing
>> the file. Your subsequent explanation ("I feel that this is going to be
>> a common use case") doesn't explain why anyone would want this
>> enforcement; it only asserts that lots of people will.
>
> Because there are use cases where the admins want to enforce lock
> reservation.
(And you present such a case at the end of this message.)
> Furthermore, I'm *only* suggesting that this be provided in
> the documentation or in a commented-out example in the pre-commit hook.
> I'm not saying that we ship it that way by default (that point seems to
> have been lost).
That point has not been lost. I accept that such an example could be useful to
demonstrate the possibilities of hook scripts in controlling locking policies,
but I still want to know why anyone would want that particular behaviour in
practice.
> The read-only bit is only a property 'hint' to the SVN client.
I assume you mean the "svn:needs-lock" property is only a hint to the SVN
client. The SVN client passes on the hint by controlling the file's read-only
permission, but other clients may not do so.
> No other client would honor it
I bet some will - e.g. TortoiseSVN.
> - therefore, the original intent for that property
> we discussed here on dev@svn got lost somewhere (oh well).
No, we discussed the requirements and came up with a reasonable design. Part
of that reasonable design is that the main functional requirement is to prevent
people wasting time on unmergeable changes, etc., and that enforcing that a
lock be held immediately before commit does not help.
> Therefore,
> 'svn:need-lock' does not affect WebDAV clients as they don't know what
> that property means.
Yup.
> WebDAV clients is a pretty serious use case in which I'm going to want
> to support in my group by ensuring they have the lock first before they
> commit any changes. The failure case right now would be that they
> *only* error out when a lock is already held by someone else. That's
> not good enough for me. I want to ensure that the client had the lock to
> begin with. I want to 'guide' my users to use locks because there are
> times when they'll need it (i.e. when it is close to 'crunch' time and
> everyone is modifying documents left and right). I don't want those
> users getting bitten by the lock process because they got lucky once or
> twice before and didn't need locks. -- justin
OK, now that's a good argument. I understand and accept that you want the lock
to be required in this case, in order to educate and remind the users about
what they are supposed to have done. It doesn't help them to achieve their
immediate goal, but it will attempt to teach them to do the right thing next time.
Thanks for explaining.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 14:01:48 2005