Oops, sorry about that, didn't read your post very carefully, and I see
now that you were talking about server side scripts. Teaches me to email
when I'm tired...
As for the motivation of the feature you actually asked about, I'm
afraid I'm less knowledgable, but I believe that it was to avoid
implementing multiple competing interfaces for the same functionality
and as a result steepening the learning curve for new subversion users.
-Brad
Brad Kittenbrink wrote:
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Oct 6 05:21:32 2005