On Wed, Feb 18, 2009 at 08:58:14PM -0500, Joshua Bronson wrote: > On Tue, Feb 17, 2009 at 3:54 PM, Randall Leeds <[1][email protected]> > wrote: > > On Tue, Feb 17, 2009 at 10:14, Jeff Hammel <[2][email protected]> > wrote: > > version of trunk that is effectively in the 0.11 series). Guaranteed > it *will* break post-commit hooks, unless someone wants to write a > plugin to, um, make this not so (shouldn't be hard, I would hope, > though honestly git horrifies me). > > In what sense would it break post-commit hooks? > I've never set up a trac instance, but poking around the trac.ini for > the melkjug project I see only the TicketChanger post-commit hook. From > what I gather from [3]http://trac-hacks.org/wiki/TicketChangePlugin I > don't see what this plugin has to do with the chosen SCM backend. > > -R
The issue isn't that TicketChanger is SCM specific (its not, or shouldn't be, in any case, though its only been tested via SVN). The webpage referenced is for a completely unrelated plugin (sorry for the naming confusion!). The home of RepositoryHookSystem is http://trac-hacks.org/wiki/RepositoryHookSystemPlugin. As the diagram shows, the plugin-points (like TicketChanger, http://trac-hacks.org/browser/repositoryhooksystemplugin/0.11/repository_hook_system/ticketchanger.py) should be SCM agnostic. However, they still need something to plug into. For SVN, this is http://trac-hacks.org/browser/repositoryhooksystemplugin/0.11/repository_hook_system/svnhooksystem.py . For Git (and everything else, for that matter), this layer remains unwritten. > If you look at [4]http://trac.openplans.org/melkjug/admin/repository_hooks > you'll see some svn-specific stuff there, but assuming git has similar > commit hooks I don't think it would be very hard to change this over. I'm > happy to pair on this with Jeff and/or work on it alone for if and when > the time is right. Would be awesome. I have no idea how Git deals with "commit hooks" or really much about how it works, but if its similar to SVN (e.g. files that live on the filesystem) it should be trivial to make a GitHookSystem comparable to the SVNHookSystem in http://trac-hacks.org/browser/repositoryhooksystemplugin/0.11/repository_hook_system/svnhooksystem.py . > One other nit is that when I created our [5]commits mailing list I lacked > sufficient foresight to give it a general name and address (fortunately I > didn't make that mistake when I made [6][email protected] > for Trac emails). I vote for > retiring [7][email protected] when we switch and > setting up a new melkjug-commits list, but if anyone has a strong opinion > otherwise, I defer. > P.S. All the enabled checkboxes > on [8]http://trac.openplans.org/melkjug/admin/repository_hooks are weirdly > unchecked but the hooks are definitely working (at least the last time I > tried "[closes XYZ]" in a commit message Jeff's awesome Repository Change > Listener plugin (see > blue:/usr/local/topp/trac/current/src/RepositoryHookSystem) kicked in and > closed the ticket. Yeah, I'm aware of this issue and its noted. The SVNHookSystem (actually, a parent class) parses the commit hook file and looks for it being enabled. In this case, the parse fails, probably because a symlink vs canonical path issue. I've noted the issue (which i thought was noted before, but i guess only in my mind). http://trac-hacks.org/ticket/4661 The other bug on this page (which i think is fixed in trunk) is that enabled is a checkbox. The apache process does not have permission to write the hook, so trying to save any changes TTW does not work. Worth noting. Jeff -- Archive: http://www.openplans.org/projects/melkjug/lists/melkjug-development-list/archive/2009/02/1235055266739 To unsubscribe send an email with subject "unsubscribe" to [email protected]. Please contact [email protected] for questions.
