You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mathias Weinert <ma...@gfa-net.de> on 2006/03/01 08:54:00 UTC
Re: [PATCH] pre-update and pre-getfile hook
Referring to http://svn.haxx.se/dev/archive-2006-02/0304.shtml Max Bowsher wrote:
> The efficiency implications are major, and the extreme inelegance of
> forcing the user to essentially do access control in two different ways,
> just because of details of Subversion's internals, is quite unpleasant.
> I realized I didn't have anything more productive to say than "This
> scares me. I won't be involving myself in this feature", and left the
> message well alone, hoping someone else would have something more useful
> to say about it.
I agree with you that now as we have per path access control for
svnserve these hooks aren't as important as they've been. But on
the other side they could be used for other things like logging,
preventing people from checking out too much (e. g. root) as
recently discussed in another thread or blocking certain IP
addresses.
What exactly do you mean with "The efficiency implications are
major"? Would the hook significantly slow down things?
Mathias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] pre-update and pre-getfile hook
Posted by Peter Lundblad <pe...@famlundblad.se>.
Mathias Weinert writes:
> Referring to http://svn.haxx.se/dev/archive-2006-02/0304.shtml Max Bowsher wrote:
>
> I agree with you that now as we have per path access control for
> svnserve these hooks aren't as important as they've been. But on
> the other side they could be used for other things like logging,
> preventing people from checking out too much (e. g. root) as
> recently discussed in another thread or blocking certain IP
> addresses.
>
> What exactly do you mean with "The efficiency implications are
> major"? Would the hook significantly slow down things?
>
Depends on how often it is invoked. If it would be invoked for each
path, that probably is a performance problem. Look in
subversion/libsvn_repos/hooks.txt. That's a design doc for the
current hooks with further ideas on "read sentinels" - basically a
hook that will be started once and notified for each path processed
with the ability to stop the operation. Might be useful if we want
read hooks-
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] pre-update and pre-getfile hook
Posted by Max Bowsher <ma...@ukf.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Mathias Weinert wrote:
> Referring to http://svn.haxx.se/dev/archive-2006-02/0304.shtml Max Bowsher wrote:
>
>> The efficiency implications are major, and the extreme inelegance of
>> forcing the user to essentially do access control in two different ways,
>> just because of details of Subversion's internals, is quite unpleasant.
>> I realized I didn't have anything more productive to say than "This
>> scares me. I won't be involving myself in this feature", and left the
>> message well alone, hoping someone else would have something more useful
>> to say about it.
>
> I agree with you that now as we have per path access control for
> svnserve these hooks aren't as important as they've been. But on
> the other side they could be used for other things like logging,
> preventing people from checking out too much (e. g. root) as
> recently discussed in another thread or blocking certain IP
> addresses.
>
> What exactly do you mean with "The efficiency implications are
> major"? Would the hook significantly slow down things?
Many invocations of it would (as has been mentioned already).
However, of *greater* concern to me is the extreme inelegance of
dividing read-control between two separate hooks. If we implemented
this, I believe it would cause widespread confusion. We should NOT be
exposing the report vs. individual-get implementation detail in this case.
Max.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
iD8DBQFEBcZLfFNSmcDyxYARAjb1AKChZFxhljdMKDjFcpOJ1yYZo+qj0gCgyU7k
wywfu5PJNiE0LKt5riodQnQ=
=iuX6
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org