On Apr 12, 2005, at 11:39 AM, C. Michael Pilato wrote:
> Ben Collins-Sussman <sussman@collab.net> writes:
>
>> Yet when I read your mail, it looks much the same as cmpilato's: I
>> see some sort of hatred of locks, or some perceived
>> danger/annoyance, with no explanation. Can we have a rational
>> debate, other than just blind voting?
>
> Hatred of locks? Oh, please.
>
> Perceived danger? Er. No.
>
> Perceived annoyance? Yes. In fact, two of them.
>
> First, we keep our repository running the most recent release so we
> can eat our own dog food, yes, but that is a far cry from treating
> that repository as a testbed. I don't want my (or anyone's else's)
> work hindered because some well-intending developer is "testing"
> locking on our live repository.
Ah, understood. I can see that it might get annoying.
>
> Secondly, since we're aren't going to be "testing" locking using our
> repository (see above), it follows that the only type of locking in
> use there will be real, I-gotta-lock-to-save-folks-from-wasting-time
> locking. And I think that lock emails play a key role in preventing
> people from wasting time.
This I agree with... we should set the svn:needs-lock property on some
binary files, perhaps some images in www/ or something, at leave it at
that. We could have a pre-lock hook that rejects a lock on anything
that *doesn't* have an svn:needs-lock property already.
I don't think we need to block on teaching mailer.py to send
lock-emails. Yes, it's a nice extra bit of communication. But since
(I believe) all svn developers use reasonable editors, the
svn:needs-lock property isn't in a danger of being accidentally ignored
(hijacked). While it's nice to get an active email saying that you
locked an image file, it's also perfectly fine for me to discover that
fact when I run 'svn lock', no? It doesn't seem like a blocker to me.
svn:needs-lock is one type of communication, mailer.py is a 2nd type of
communication. I don't think we need to have both features in order to
start making basic use of locks.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 18:56:04 2005