On 5/3/06, Greg Hudson <ghudson@mit.edu> wrote:
> My position:
>
> 1. Checking out /tags, /branches, or their parents is a real problem,
> though apparently a tolerable one, and one we should address, but it
> isn't an authorization problem; it's a performance safety measure. If
> it doesn't fit nicely into the authz file, we should invent a new
> mechanism rather than squeezing it into the existing one.
My only concern here is that any new mechanism to control that sort of
thing is likely to do things that are virtually identical to our
existing authz system. Do we really want to have two things doing
almost the same thing?
> 2. You're hugely overblowing the severity of the replay problem.
> Checking out /tags or /branches or their parents is bad because has a
> multiplicative cost; a 1MB trunk with a hundred tags generates 100MB of
> data on a checkout of /tags. Replay, on the other hand, is quite
> efficient; it gives you exactly as much data as you need. Moreover,
> people who want to use that kind of functionality are already
> synthesizing it from other operations today, so it's unlikely that
> replay is going to create some kind of new load issue. I don't object
> to putting replay controls in the performance safety mechanism mentioned
> above, but I don't think there's any need to have that in the same
> release as replay goes into.
The problem with replay is that the tool we provide that exposes it is
svnsync, which has the default behavior of sucking down all history in
a given repository. Sure, we may not have the multiplicative
behavior, but we've still got a depth problem there, for a very large
repository it can be just as bad as checking out the root of the tree.
Perhaps a useful way to avoid some of the problem is simply to change
the behavior of svnsync, have it only copy a revision at a time or
something, so at least people who pick up the shiny new toy won't
cause problems right off the bat the first time they try it, they'd
have to at least write a script to do that ;-)
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 4 02:16:32 2006