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

Re: Ways to keep users from checking out too much.

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-02-22 23:10:31 CET

On 2/22/06, C. Michael Pilato <cmpilato@collab.net> wrote:
> C. Michael Pilato wrote:
> > Garrett Rooney wrote:
> >
> >
> >>Honestly, I don't care one way or another if they can --force it or
> >>not. Checking out trees that large puts an unacceptable amount of
> >>strain on a public resource in this case, I just want to be able to
> >>stop them from making silly mistakes that require administrator effort
> >>to block, and reserve the admin effort for the cases where people are
> >>actually doing this kind of thing on purpose. If they can add --force
> >>and make it work, that's nice, but it's not really a showstopper IMO.
> >
> >
> > Um... aren't you the guy that just implemented the equivalent of
> > 'svnadmin dump' over the RA layer? Does that not generate a similar
> > level of system strain?
>
> Sorry! That's got a good chance of reading like, "You can't complain
> because you're a troublemaker of the same flavor!"
>
> What I mean is simply, "There are probably lots of ways to put strain on
> a Subversion server. Which of them are you wanting to block, and if not
> all of them, why not?"

I accept the fact that there's no way to keep a determined user from
DOSing the system, when you run a publicly accessible server you just
have to live with that and be able to block that traffic at other
levels if needed. What I do want to be able to do is make it
sufficiently hard to do that a user won't be likely to do it
accidentally.

-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 23:13:23 2006

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.