[Fusionforge-general] [Fusionforge-commits] r8564 - in trunk/gforge/plugins: cvssyncmail/[...]

AlJeux aljeux at free.fr
Fri Dec 18 18:13:48 CET 2009


Hi Roland,

I have something which is not very far from what you're talking about.

Here is an example using SVNCommitEmailPlugin

function SVNCommitEmailPlugin () {
	[...]
	$this->hooks[] = "cmd_for_post_commit_hook";
}

function CallHook ($hookname, $params) {
	[...]
	} elseif ($hookname == 'cmd_for_post_commit_hook') {
		$params['hooks'][$this->name] =  '/usr/bin/php -d 
include_path='.ini_get('include_path').' 
'.$sys_plugins_path.'/svncommitemail/bin/commit-email.php 
'.$params['repos'].' "$2" 
'.$params['unix_group_name'].'-commits@'.$sys_lists_host;
	}
}

So, in this model, svn hooks are easier to add and maintain but the svn 
post commit hook file is still constructed. This solution has an small 
speed advantage of not calling fusionforge hooks if there is no hooks in 
place.

Alain.

Roland Mas a écrit :
>   This mail is completely unrelated to Alain's commit, but it just
> reminded me to share an idea I had recently.
> 
>   There are several plugins that do stuff on commit.  The matrix is not
> too complex since we only have {cvs,svn}×{commitemail,tracker} so far,
> but it may grow with combinatory complexity once we want to add new
> verson control systems and new features (continuous integration, or code
> metrics, or whatever).  So I was thinking we could go from O(n×m) to
> O(n+m) with the following idea:
> 
> - each scm plugin automatically adds *one* commit hook to its
>   repositories, which calls fusionforge-commit-hook.php;
> 
> - that fusionforge-commit-hook.php script is almost empty, except that
>   it calls the “post_commit” hook in FusionForge;
> 
> - the “triggered” plugins can be factored into generics: scmtracker and
>   scmcommitemail and so on; if they subscribe do the post_commit hook,
>   they'll get called by all scm* plugins when there's a commit.
> 
>   It's not a trivial change, of course, since the scm* plugins would
> probably have to include methods to give the triggered plugins the
> required information on the new revision, but I think it's a valuable
> change for the long-term.  I don't have any brain cycles available to
> implement that right now, but I though I'd submit the idea anyway, in
> case anyone is feeling bored.
> 
> Roland.





More information about the Fusionforge-general mailing list