--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.
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).
The read-only bit is only a property 'hint' to the SVN client. No other
client would honor it - therefore, the original intent for that property we
discussed here on dev@svn got lost somewhere (oh well). Therefore,
'svn:need-lock' does not affect WebDAV clients as they don't know what that
property means.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 07:41:28 2005