[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Issue 533] New - implement reserved checkouts

From: Jim Blandy <jimb_at_red-bean.com>
Date: 2002-08-04 18:42:02 CEST

Martin Pool <mbp@sourcefrog.net> writes:
> One thing that *really* bugs me about this system is that as far as I
> can see there is no escape: if somebody has a file locked, then only
> they or the administrator can unlock it. If you're in a different
> timezone to all the administrators that is a real pain. I feel pretty
> strongly that there ought to be a --force option that lets you go
> ahead and break the lock, and deal with the consequences later. (You
> can't even fudge the file permissions in your own view to make it
> build, because CC hooks the filesystem level, but that's a whole other
> rant.)

This kind of techno-fascism always cracks me up, because it's
completely ineffective. You can always just make a copy of the source
tree, and work in your copy, right? So even though ClearCase provides
its own filesystem front end and can even frustrate an explicit chmod,
it's *still* just an advisory lock.

(Now, once we all have Fritz chips monitoring our motherboards for
unclean thoughts: http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html
they'll even be able to keep us from making that copy. But I
digress. :) )

I think people often avoid confronting interpersonal problems by
imposing policies, or using technologies, that, on their face, don't
single out anyone in particular, but, in effect, prevent or work
around a particular individual's problems. But these policies often
make life mildly more annoying for everyone.

For example, a few years ago, I took a ridiculously long time to get
around to looking at a patch to GDB that was completely, obviously,
the right thing to do. It didn't require any expertise to evaluate
--- everyone could tell it was the right thing. Eventually, the
author of the patch blew his top and complained that obvious fixes
shouldn't take this long to review. In response, GDB adopted an
"Obvious Fix" policy, which allows people to commit "obvious" changes
without review. This usually works out fine, but sometimes really
questionable stuff gets through; people's sense of what is obvious
seems to depend a little bit on how desperate they are to get their
patch in.

I don't like the policy much. If a change is obvious, it doesn't take
long to review, right? So if your reviewers aren't totally out to
lunch (as I was), then you don't need an "obvious fix" policy, and you
don't get the bogosities either. It's better to beat up on your
reviewers a bit, to keep them awake.

Anyway, this is one reason I am skeptical about explicit locking: in
the back of my head, I'm always wondering if there isn't some
difficult individual on the team who's the real problem. It's a shame
to impose annoyances on all the people who do work well with the group
just because of a jerk or two.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 4 18:42:53 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.