> But, say I'm on a Linux machine -- how do I tell which processes have
> a lock on the repository? (Actually, the first question is why "svn
> recover" doesn't print a list of those locks and exit with an
> explanatory message.)
Partial answer: fuser(1). I just used it to find five svnserve
processes that have my repository open. I had permissions to kill
four of them. (There was only one other user logged in, so they were
hung from failed accesses.)
So, why didn't "svn recover" already have code in it that checked to
see if the result of fuser(1) on the db files and locks is nonempty?
And if it is, to issue a nice informative message "Aborting -- processes
xxx yyy zzz have the database open, I can't proceed while it's locked."?
It took me all of five minutes and one skim through a manual page to
come up with a technique for guarding "svn recover" so a large class
of hangs will never happen *and* stuck repo admins will have an
obvious recovery path. You guys are all smart enough to have thought
of this faster than I did *if you were paying any attention to
usability*.
The obvious deduction is that you weren't paying any attention.
Instead, in the last couple hours I've gotten neat little lectures from
three of you on how one has to make sure no processes have the
database open before trying a recover. It's obvious that for all
three of you your thinking got just that far and stopped dead at the
same place.
People, your job as software designers is to *keep asking the next
question*, which in this case is "how can we gather the
locking-process information so the poor panicked repo admin doesn't
have to"? Maybe fuser(1) isn't the whole answer, but it should have
occurred to somebody here to start there without my having to yell
about it.
You know, I'm very seldom rude by accident. It usually happens whenn
I see that people have screwed up not because they were stupid but
because they were *lazy*. Stopped thinking. Didn't question their
premises. Accepted too narrow a problem definition.
Well, that's what this crew did and I'm calling you on it --
instead of simply writing you off and walking away, which is what
I'd do if I thought you were idiots.
Hell, I'll write the patch for this bug if that's what it takes. The
real point is this: WAKE UP! Please, for everyone's sake, start
asking yourself what other unnecessary usability botches you're
carting around *and fix them*. Please -- start designing as though
your users mattered.
--
Eric S. Raymond
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Aug 25 10:25:55 2004