Changes between Version 12 and Version 13 of RepositoryHookSystemPlugin
- Timestamp:
- Jan 2, 2009, 3:14:15 PM (15 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
RepositoryHookSystemPlugin
v12 v13 17 17 * the listeners are invoked via a command-line call from one of the repository hooks. This is a one-line command that passes whatever details are necessary to identify the changeset. 18 18 19 * a trac changeset object is used to pass around information. This is good, as it avoids unneccessary information to be sought by the !RepositoryChangeListeners. For the SvnChangeListenerPlugin (at least as it stands living only in the post-commit hook), this is sufficient. It is unknown whether this is a good idea for other hooks and repository systems. If a unified interface for a changeset object were available, then a changeset object could be "fakeable" if its not available (like it is at SVN post-commit). If not, this is a big conceptual hole. ''To be investigated.''19 * a trac changeset object is used to pass around information. This is good, as it avoids unneccessary information to be sought by the !RepositoryChangeListeners. For the SvnChangeListenerPlugin (at least as it stands living only in the post-commit hook), this is sufficient. It is unknown whether this is a good idea for other hooks and repository systems. A changeset object can be faked if it is not available (like it is at SVN post-commit). 20 20 21 21 * the logic of the !RepositoryChangeListeners is agnostic to SCM type and hook used. … … 26 26 This is similar in concept to the SvnChangeListenerPlugin, but the architecture is also designed to support 27 27 28 * arbitrary version control systems, with an &adapter;for the version control system used to an implementation capable of hook invocation28 * arbitrary version control systems, with an adapter for the version control system used to an implementation capable of hook invocation 29 29 30 30 * arbitrary hooks, not just post-commit