Ben Collins-Sussman <sussman@collab.net> writes:
> > 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.
Cool.
> > 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.
Alrighty, that's cool. I follow your reasoning, and concur.
So how about if I make the pre-lock hook script disallow locks on
paths that don't have svn:needs-lock set? That way, we limit our need
for communication mechanisms to the one mechanism we currently have.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Apr 12 19:06:20 2005