osimons wrote: > That just strikes me as a bit... unexpected... Like all listeners in > Trac, I assume these methods will fire whenever sync() picks up a new > changeset or resyncs and old one, and not be something that needs > repository hooks and command-line calls?
There are several reasons why this is not the case: - Performance: with multiple repositories, we cannot afford anymore to try and sync them all for every request. This is highly inefficient: syncing once per request, when all that is needed is once per commit. - Consistency: what would you do in case of a complete resync? Fire the listener for all revisions? For none? Or should we keep track of every changeset where the listener has been fired (as not all VCS have linear history)? What should we do when a repository is removed, and possibly re-added with another name? That second part is important for plugins that mutate some other data based on commit information, for example the ticket updater. Firing the listener twice for the same changeset would result in two entries for the tickets referenced by the changeset message. By calling the listeners from the post-commit hook, we are sure to call the listeners once, and only once, per changeset. > It just feels very un-Trac > with regards to API and implementation - and what any plugins may > reasonably expect from the core configuration. I'm not sure I understand the part about the plugins, but I'm certainly open to suggestions how this could be done differently, with reasonable performance and complexity. Myself, I haven't been able to come up with anything better. > It is also an > additional burden for administrators that needs to keep code, hook- > scripts and configurations coordinated to make this work - now also > across multiple repositories that may be added, moved or removed... Sure, you have a point. OTOH, I don't expect adding and removing repositories to/from a Trac instance to be a frequent operation (the future may well prove me wrong), so it's more a matter of setting up correctly at the start. Then again, if you set up new Trac instances daily (as I know you do), it's certainly more work. Note that you still have the option to sync one, several or even all repositories of a Trac instance on every request. This is even the default for the default repository. But the changeset listeners will not be called in this case. Of course, we will document that in the guide (it won't make it less work, though). > Not to mentioned the cases where the repository is scoped, and > changesets may need to be distributed to a variety of different Trac > instances. Right, that would need one call per Trac instance in the hook for that repository. > It just feels wrong... Any change of removing this "external" element? What can I say... Suggestions and discussion welcome? -- Remy
signature.asc
Description: OpenPGP digital signature
