On 2/22/06, C. Michael Pilato <cmpilato@collab.net> wrote:
> Garrett Rooney wrote:
> > How would people feel about some mechanism for stopping update reports
> > rooted at particular directories? It might at least prevent the
> > accidental foot shooting you get when an inexperienced user first
> > tries their hand at a svn checkout, and that would be a nice step in
> > the right direction.
>
> That is a very odd feature request if expressed as something you'd want
> to put into Subversion itself. It's the kind of thing that would work
> well if we had (as many folks have asked for) read hooks in the
> repository, but ...
>
> Are you sure you aren't asking for a Band-Aid (tm) to cover up some
> performance or cancel-ability problems in Subversion that would be
> better fixed directly?
Well, if checking out the root of a tree with lots of tags and
branches in it didn't take so damn much CPU and IO, this would be less
of an issue, but I suspect we're in one of those categories where it's
a matter of "well, you asked it to do X, why are you surprised when it
takes a while".
It's not so much an issue of cancelability, I suspect the user could
cancel it out any time they so desire, but by the time they've
realized it's a problem they've been using a big chunk of our CPU and
disk bandwidth for several minutes, which is kind of uncool. And
that's if it's an accident, if it's not accidental then they have no
desire to stop it.
One thing that might be handy would be an easier way to detect these
kind of users. Right now, it's a matter of noticing that we've had a
httpd child process sucking up CPU for 5 or 6 minutes, checking
server-status and seeing that they're doing a REPORT, and then
stracing the process and confirming that yes, they seem to be hitting
multiple tags within the same directory and probably checking the svn
operational log to see if they've done similar stuff earlier in the
day. It's a bit of a pain.
But even if this was easier, it'd still be nice if we could just stop
them from doing it in the first place without actually blocking
anonymous access totally.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 22 22:51:33 2006