I am not a subversion developer, but here's my recollection of the
conversation the last time this was brought up.
If your intended use is to have svn trigger some script or executable
which is already installed on each client, you can trivially get this
functionality with some kind of shell script wrapper for either svn as a
whole or for the individual svn subcommands in question..
If your intended use is to have svn download some script or executable
from the repository and automatically execute it on the client, then I
believe this was dismissed since it would open up a potential weak link
in the security of subversion. A compromized public svn server could
theoretically immediately spread the infection to thousands of client
machines.
Furthermore, if you deploy a solution for the first use case, then it
can be straightforwardly extended to download and execute a script from
either a fixed location in the repository or a location specified by a
property in the repository. This solution was determined to be easier
for site administrators to configure than the plethora of security
options that would be required to properly implement any potential
native solution to this feature request.
I may be imagining this, but I think someone suggested that if a good
set of such scripts was developed, they might make it in to the
contrib/client-side part of the subversion repository, but I don't see
any such scripts there.
-Brad
ps - I think the user list was the right place for this question, sorry
I wasn't there to answer it for you.
Fernandes, Filipe (Bolton) wrote:
>I guess I should have really sent this to dev mailing list,
>as it's more a question of why than of how.
>
>I had posted a question on the users mailing list wondering
>if there were any plans to create pre/post checkout/update
>scripts to be a part of the subversion hooks library of
>calls.
>
>This would allow for a finer level of control when it comes
>to logging and controlling access to code that the apache
>logs and AuthzSVNAccessFile directive really don't provide.
>(ie.. who gets access to what and when).
>
>The reply to the user post I made had the suggestion of
>using the custom logging features that will be comming
>out soon, but this really isn't a hook that could stop an
>action if it's undesireable.
>
>http://svn.haxx.se/users/archive-2005-10/0099.shtml
>
>I guess my question is... what's the impetus for not
>providing those 'read' hooks? It seems that people in
>the past have asked for these hooks, but not so clean work-
>arounds were suggested. Is there a philisophical reason for
>not providing them, or an implementation reason?
>
>filipe
>
>ps: Please don't take the above a critisism; if anything
>a 'feature request'. Subversion is a great resource and I
>look forward to future releases.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 6 04:46:57 2005