Garrett Rooney wrote:
> So Lundblad and myself, along with other random passers-by on
> #svn-dev, have been talking about the replay authz stuff that we've
> been trying to get in before 1.4, and we figured it should be
> summarized and sent to the list.
I've been one of the people clamouring for this feature, but my interest
in it has just diminished greatly -- I'm leaving the company where I'm
currently svn admin, going (back) to a company that's stuck eternally on
cvs for political reasons, so my interest is now mostly academic. :)
> Basically, the desired change to authz would be something like this.
> We add a new permission that controls the ability to execute
> operations that recurse through an entire subtree, which includes
> things like update, checkout, diff, merge, status -u, and replay.
> This is possible to implement, although it is tricky in some spots.
I really like this simplification of the issue. It solves all the
outstanding problems I've seen quite nicely.
> The problem with this is how is it configured in the authz config
> file?
Nicolás Lichtmaier wrote:
> Have "r" mean "full read access including recursive reads", and add a
> new "a" (access?) meaning "just access, no recursive ops". So all
> the "*=rw" would still be full access and this new feature will be
> used just by those who explicitly activate it.
>
> The thing is... does this look good? Is it clean to have a permision
> implying another? It's an esthetical issue.
I really like this suggestion. The objection can be overcome by also
introducing "c" for reCursive access, and then simply defining "r" as a
shorthand for "ac". It can even be sanely documented without invoking
the backwards compatibility crutch, since both "reAd" and "reCursion"
start with r. :)
Garrett Rooney wrote:
> Next, there's the issue that people now really need to carry around
> this new permission all over the place, whenever they add a more
> specific rule.
With the r shorthand available, I'm not sure that I see this as a
problem. It will be quite natural to just accidentally do the right thing.
> Lundblad wants to allow things like +w or -w, inheriting the rest of
> the perms from parent directories, but like I said, that's a bit of
> work because we currently don't have anything like that, and it has
> potential performance implications due to requiring us to look further
> up the directory tree before we can be sure about a given answer.
I think that would be nice syntactic sugar, but I don't see it as being
at all required (from a users perspective) for this new authz syntax to
be acceptably usable.
> At this point in the conversation, we started to wonder if it was even
> possible to implement a good authz based solution in a reasonable
> amount of time, especially taking into account that you really don't
> want to drop a massive authz change in right before a release. So we
> started to consider alternative plans.
Greg Hudson wrote:
> 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.
I agree 100%. While this would be a great feature to add, I don't think
that replay alone makes it a release blocking requirement.
Garrett Rooney wrote:
> 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 ;-)
That seems quite wise. Even just requiring a command line switch to
sync the entire repository in one go, with a warning about performance
in the --help string, would be more than enough, IMO. As has already
been stated many times, people are already doing exactly what replay
does, in a much less efficient manner. As long as you can avoid
introducing more _accidental_ DOS's caused by people trying out the tool
in it's default mode, you've met your responsibility to not make things
worse by introducing replay in 1.4 without authz recursion control being
available.
- Marc
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 4 13:19:17 2006