[Fusionforge-general] Question regarding svntracker / cvstracker and proposal for different approach

AlJeux aljeux at free.fr
Tue Jun 1 13:28:05 CEST 2010


JL Bond Consulting a écrit :
> On Tue, 2010-06-01 at 11:21 +0200, Roland Mas wrote:
>>   I propose a different approach: the scmsvn plugin (and the same
>> applies to other scm* plugins) only adds *one* hook to the repositories
>> it creates, and never touches it afterwards.  However, that hook only
>> calls an external script that is in charge of actually doing whatever
>> real actions are required (commit email, link to trackers, trigger CI
>> jobs, whatever).  That real script can be regenerated from time to time
>> to take into account new options configured via the web; alternatively,
>> if it can be run with appropriate privileges (database access), it can
>> determine at run-time what actions need to be undertaken and act
>> accordingly.
>>
>>   This approach limits the risk of users changing the hooks (if the
>> actual script is outside of the "post-commit" file); also, it's rather
>> extensible since it allows new plugins to add actions without requiring
>> a change in the repositories' hooks, since they only need to provide a
>> bit of code to add into the generated script.
> 
> Ok, I see your point and agree. Less mucking around with the subversion
> hooks is best. Also, once the scmsvn is hooked into repositories as they
> are created, then there will be no more delays between
> activating/de-activating other svn related plugins that hook into
> subversion.
> 
> So, along those lines, we can have:
> 
> $GFORGE/plugins/scmsvn/hooks/run-hooks.ksh
> $GFORGE/plugins/scmsvn/hooks/{start-commit,pre-commit,post-commit,pre-revprop-change,post-revprop-change}->run-hooks.sh (symlinks)
> $GFORGE/plugins/scmsvn/hooks/{start-commit,pre-commit,post-commit,pre-revprop-change,post-revprop-change}.d (directory, apache:apache, 0750)
> 

An alternative could be to write your run_hooks in php and then you
would have something like:

<?php

require dirname(__FILE__).'/../../env.inc.php';
require $gfwww.'include/squal_pre.php';
require_once $gfcommon.'include/Plugin.class.php';
require_once $gfcommon.'include/PluginManager.class.php';

setup_plugin_manager() ;

$params['unix_group_name'] = $unix_group_name;
$params['repos'] = $repos;
$params['hooks'] = &$hooks;
plugin_hook('svn_post_commit_hook', $params);

?>

This way, in the svntracker, you just register the plugin to be called
on this hook and have to implement the action in the
svn_post_commit_hook. The result is less code & less scripts.

Alain.

> and run-hooks.ksh can be like:
> 
> #!/bin/ksh
> HOOKS_DIR=${0}.d
> for hook in `ls ${HOOKS_DIR}/*`
> do
> 	if [[ -x $hook ]] ; then
> 		$hook $@
> 	fi
> done
> 
> The actual subversion hook would simply call, e.g., for post-commit:
> $GFORGE/plugins/scmsvn/hooks/post-commit ${REPOS} ${REV}
> 
> Then, other svn related plugins (i.e., svntracker, svncommitemail) can
> simply drop their hook scripts into the appropriate directory under
> 
> $GFORGE/plugins/scmsvn/hooks/{start-commit,pre-commit,post-commit,pre-revprop-change,post-revprop-change}.d
> 
> This can be done via
> $GFORGE/plugins/${plugin_name}/scripts/${plugin_name}-init.php ???
> 
> Would that be good approach?
> 
> -Bond
> 
> BTW, I like the idea of a task/job scheduler. I suppose that would have
> to be separate process running as daemon perhaps?
> 
> 
> _______________________________________________
> Fusionforge-general mailing list
> Fusionforge-general at lists.fusionforge.org
> http://lists.fusionforge.org/cgi-bin/mailman/listinfo/fusionforge-general
> 





More information about the Fusionforge-general mailing list