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/


Reply via email to