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

Re: Is our revprop auth policy too strict?

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2007-05-21 16:48:37 CEST

On Mon, May 21, 2007 at 10:22:15AM -0400, C. Michael Pilato wrote:
> > Given that we already have revprop change hooks, aren't you actually
> > asking: "should Subversion force a read-only policy for the partial
> > access case"? And given that, I'd say the answer is emphatically not:
> > there are some policies that are worth enforcing in the core, but this
> > doesn't seem like one of them - let the hook dictate the policy, it's
> > what it's there for.
>
> Sorry to be annoying, but are you advocating a staged write access in the
> core that matches our staged read access -- the "if you can see it, you can
> change it" policy? Or are you saying we should leave all write-blocking to
> the hooks?
>

Heh. I'm saying we should go for the former ("iif you can see it, you
can change it"). You're right that my position also suggests the
latter, though I'll handwave away the contradiction by pointing out that
because we already enforce read policy in the core, it's better for
consistency to use the same logic to enforce write policy than to say
"oh, we already have a general write policy mechanism, let's use that
for writes, but enforce policy for reads ourselves".

Best of all might (_might_) be to delegate both read- and write-policy
down to hooks and drop all notion of policy in the core completely,
though that might be too complex to bother with (really, how common are
partial-access commits?).

> Oh, I've already got a patch ready for commit that does the easy-detection
> (for scripts that use the APIs/bindings. :-) That's no sweat.
>

Ex-cellent :-)

Regards,
Malcolm

  • application/pgp-signature attachment: stored
Received on Mon May 21 16:48:49 2007

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.