On 4/25/06, Greg Hudson <ghudson@mit.edu> wrote:
> On Tue, 2006-04-25 at 14:56 -0700, Garrett Rooney wrote:
> > I figured getting something out there for replay alone was better than
> > not getting anything out at all.
>
> Disagree. There is already code out there, in wide use, to synthesize
> replay using less efficient operations.
Ok, I can buy that argument. I've played around with versions of this
that block update style requests, and I'm pretty sure I can make it at
least sort of work (the generality of update-report is totally
screwing us here, because it's going to be really hard to block
checkout/update/switch without blocking things that are actually
useful to allow, like diff, but whatever, I can make something work),
but I've hit a usability snag. I think in order for this stuff to be
useful we're really going to need wildcards in paths in authz config
files.
For example, say you're the ASF Subversion repository. You'd really
like to block checkouts of anything from / to the root of any given
project. So it's invalid to check out /, /apr, /apr/apr-util,
/apr/apr-util/tags or /apr/apr-util/branches but not
/apr/apr-util/trunk or anything under /apr/apr-util/tags and
/apr/apr-util/branches.
To get this kind of behavior we either need to have nonrecursive authz
permissions, which means each and every path that you want to block
checkout of needs to be tagged in the authz conf file, which would
really suck, or we need wildcards of some sort. Adding wildcard
support without having it devolve into "ok, now we enumerate all
sections in the file and see if any of them match" seems like it will
require some thought...
So before I dive into the whole "how should wildcards work" mess any
further than I already have, has anyone thought about that sort of
thing yet? Anyone got a design proposal sitting around that they
haven't sent out yet?
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 28 07:01:12 2006