On Tuesday 13 August 2002 11:32, Branko Čibej wrote:
> >I see locks as more than a communication system. For normal
> > communication, which even I agree does not need to be versioned (although
> > I do save all of my email), email and IM work fine. But locks also tell
> > me when and why a person has locked something, and can generally be used
> > to see what a person is working on.
>
> How is this different from a communications system?
I'm not saying it isn't. It is. This is part of the reason why history
should be saved (see bottom).
> > If someone locks something and doesn't work on it, then
> >history could be used to prove that that person is abusing the system.
>
> Oh, so you'd overload locks to be a performance evaluation tool, too.
No, not exactly. I'd just use them to see what everybody is working on at
them moment. And I'm talking about abusing the locking system, not the dev
system in general.
One of the big problems I had with Visual Source Safe was that people were
lazy, and they'd just recursively lock entire trees related to what they were
working on. Everyone here I'm sure has experienced this problem. Well, it
might be nice to take a copy of the lock history (svn log | grep '^Lock:' or
something) to a manager and say, look, so-and-so is causing problems. Source
Safe didn't have any way to see what had been locked by whom in the past, and
I wish it had.
> Oh, so you'd overload locks to be a performance evaluation tool, too.
> But we have those already, they're called 'svn diff' and 'svn log' (and
> someday 'svn blame').
But these all show what a person has worked on in the past. Locks (unrelated
to lock history, sorry for getting these issues confused) will show,
theoretically, what a person is working on in the present.
And if it turns out that the person is taking out locks on stuff he is not
actually working on, then history could be used to make a case that the
person has abused the [lock] system. Too many locks without actually
checking in changes to those files would be an indication of abuse, and
something that a stupid bizdev project manager would see as hard proof.
Okay, this is not how things should work in a utopian developer environment.
Everyone should get along, and locks shouldn't be necessary at all. But in
the real world, people want the ability to hold other people accountable.
Managers also need performance evaluations, whether or not they have any
bearing on actual productivity. It sucks.
I'm going to drop this now, because it's getting off track from my real point.
All I want to say is that lock history would be nice, if possible (and I
think it is). Some people don't want locks polluting their revision history,
which is understandable. Locks could be held in a separate table, or even in
a separate application like you say.
But I guess my biggest reason for wanting history is so that lock log messages
don't get lost. If I send an email, or even an IM, a copy gets saved
somewhere for later reference. Without lock history, you create a
communication medium that is not permanent, and IMHO all communication should
be permanent, save verbal, especially when locks can directly affect (for
better or worse) the productivity of a project.
--
Peter Davis
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 13 21:00:22 2002