"Henderson, Michael D" <email@example.com> wrote on 11/24/2004
> I'd like to extend hooks a bit by embedding an interpreter in svnserve.
> I'm looking at solving a problem that doesn't exist, but doing so would
> the server to run a script internally rather than shelling out to a
script every time.
> I'm looking at using lua or ferite for the interpreter. lua's small and
> ferite is fun. I'm also comfortable with both. lua can pre-parse a
> which helps on repeated calls.
> Is this something that *should* be done? I don't see a lot (read "no
> clamoring for such a feature. Most of the functionality of hooks I've
> could easily be handled without calling the shell. For those that
> hook scripts could still be called.
> Plus, the interpreted scripts would be portable to other operating
> The problem that originally got me to thinking about this was ACLs. It
> to be easy (and fast) to run an interpreted script to check and enforce
> permissions. Plus, as a script, a replacement system could be dropped in
> without recompiling if the interface was identical.
> Would there be a performance hit that I'm not seeing?
> I don't use svn over Apache, so I haven't given any thought to mod svn.
> there a place/way to put in a change like this so that both could share?
Hooks are in libsvn_repos, so if you implemented a feature like this, it
would work for all access methods. Are these interpreters portable to all
of the operating systems that Subversion and APR support?
Finally, isn't there a stability advantage to running the scripts in a
separate process? Perhaps not.
It is an interesting idea. Portability of the interpreter would be my
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Wed Nov 24 21:39:21 2004