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

Re: client-side hooks (was: Prevent accidental commits)

From: Erik Huelsmann <ehuels_at_gmail.com>
Date: Mon, 16 Jun 2008 15:34:35 +0200

On 6/16/08, Vincent Lefevre <vincent+svn_at_vinc17.org> wrote:
> On 2008-06-11 17:00:26 -0500, Ryan Schmidt wrote:
> > Right, "svn lock" is not applicable, and there are no client-side hooks.
>
> BTW, since client-side hooks are mentioned from time to time,
> shouldn't they be added as a feature request on the issue tracker?
>
> They could solve other problems, such as restoring file permissions
> and providing more advanced auto-props (e.g. per repository, based
> on file contents instead of filename extension...), without needing
> a wrapper script to parse some svn output (and possibly do more work
> than necessary).

The subversion project has no intention to add client side hooks:
they're a security nuisance at least. It's a topic too hairy to touch.
However, if you want to extend Subversion, you're ofcourse free do
develop wrapper scripts, or implement the client functionality in any
of the extention languages using the language bindings.

> Note if this isn't clear: for security reasons, client-side hooks are
> written by the user of the client (just like the client config file).
> And if users want e.g. server-wide auto-props, this can also be done
> with a client-side hook that reads some config file provided by the
> server (and a server-side hook can also check things if need be).

Why not build the commit logic using the perl and/or python bindings?
99% is offered out of the box by the libsvn_client bindings...

Bye,

Erik.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-06-16 15:37:27 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.