Might want to make the ticket expression /ZF\-\d+/ just to make maintenance of the hook easier. You'll also want to prevent commits to tickets that are closed. The way that I've worked in the past with hooks like these is to use open tickets for common tasks so that all Spanish documentation updates are ZF-12345, for example, and this ticket tracks all Spanish language changes. Everything else (including general maintenance) is then tracked through a ticket. It can be a ticket like "Reorganization of repository layout" or whatever, but it helps keep everything in one place and makes it easily searchable.
For projects with a large number of committers, I've found this to be the best way to keep things organized. -Matt On Tue, Nov 4, 2008 at 4:26 PM, Ralph Schindler <[EMAIL PROTECTED]>wrote: > > Hello all, > > I am proposing we introduce a pre-commit hook on the framework subversion > repository that will help ensure that commit messages are properly > formatted > before the commit goes through. The driving factor behind this proposal is > simply integration. Ideally, we would like to see all svn commits better > formatted so that both our tools and processes can be more effective. > > So what does this all mean? > > Well, as some of you might be aware of, JIRA/Confluence/Fisheye is a pretty > robust system with lots of features. One of the more useful features is to > be able to open an issue and in the Fisheye tab, be able to see all of the > commit to the SVN repository that go along with that JIRA issue number. > > For example, take a look at this issue: > > http://framework.zend.com/issues/browse/ZF-4174 > > Once inside the issue, click "Fisheye" at the bottom. From here, we are > able to see which revision it was fixed in, can click through to that > revision, which files were changes, and the diff of the fix - all from > within the issue. Furthermore, it is easy to see if the fix was merged to > the appropriate branch. From a code management perspective this type of > information is INVALUABLE. > > There are other side consequences: better continuous integration, better > commit messages in the svn history of a file, encouragement of "atomic" > commits (* see footnote), and once we get fisheye re-indexed, it too will > have more invaluable information on a per commit level. > > All that said, this is the proposed pre-commit hook.. > > All commit messages should at least contain one or more of the following > tokens in the *first* line: > > DOCUMENTATION > or DOC-LANGUAGE (such as DOC-ENGLISH, DOC-SPANISH) > - this token is for documentation only commits > GENERAL > - this is to be avoided, but will be available for > svn maintenance and SELECT projects tasks > ZF-1234 (/ZF-[0-9]{3,4}) > - this is to be the most common format as it will > reference JIRA issue numbers for which 99% of all > commits (outside of doc translations) are for. > Generally this should only be a single issue as > multiple issues should have multiple commits. > > If you have any special concerns with this plan, please let me know, > Thanks, > Ralph > > > > Footnotes: > * "atomic commits" - each issue solved should have its own commit. This > means that if in the course of a nights work you fix 2 distinctly different > issues, for example one in Zend_Controller and another in Zend_Db, they > should each be committed to svn within their own separate commit. This > will > help in not only merging, but backing out regressive issues. > > > > -- > Ralph Schindler > Software Engineer | [EMAIL PROTECTED] > Zend Framework | http://framework.zend.com/ > > >
