Changes between Version 1 and Version 2 of Development/CommitConventions

Timestamp:

08/17/11 20:14:57 (8 years ago)

Author:

ibboard

Comment:

--

Development/CommitConventions

@@ -36 +36 @@
 }}}
 
-This format works well in both Subversion and Trac (which would munge everything on to a single line without the bullets) and using a descriptive overview of changes rather than the detail means the commit message abstracts away the detail. If someone wants to know exactly what is involved in the commit that "Added LGPL headers to all files" then they can look at the revision details and the file differences.
+This format works well in both Subversion, Mercurial, Git and Trac (which would munge everything on to a single line without the bullets) and using a descriptive overview of changes rather than the detail means the commit message abstracts away the detail. If someone wants to know exactly what is involved in the commit that "Added LGPL headers to all files" then they can look at the revision details and the file differences.
 
 === Pre-commit hook ===
 
-When you try to commit code, but before the code is actually committed, the system checks your commit message for Trac ticket references (e.g. #1 or ticket:2). You '''must''' reference at least one ticket in all commit messages or the commit will be rejected. 
+When you try to commit code, but before the code is actually committed, the system checks your commit message for Trac ticket references (e.g. #1 or ticket:2). You ''should'' reference at least one ticket in all commit messages. Since the move to Mercurial then this is no longer mandatory, but is strongly preferred. 
 
-This is generally a good thing as all code should normally be written because of a ticket. If there isn't a ticket for the feature or the bug then why is the code being written? There are, however, times when you've closed a ticket and found a bit of code that wasn't checked in (e.g. [ticket:1#comment:11 here]), or when a very short fix needs to be made where a ticket is more effort than the fix. In these situation you should reference the closed ticket (if applicable) and use the keyword "no-open-ticket" (with the hyphens). Excessive and unnecessary use of the keyword should be avoided.
+Referencing a ticket is generally a good thing as all code should normally be written because of a ticket. If there isn't a ticket for the feature or the bug then why is the code being written?
 
 === Post-commit hook ===
 
-So that you don't have to update Trac manually, we also have links from the commit message to referenced Trac tickets. These let you tie commits to a ticket, leave comments on the ticket and close the ticket without accessing Trac directly and copying what you just sent to Subversion.
+So that you don't have to update Trac manually, we also have links from the commit message to referenced Trac tickets. These let you tie commits to a ticket, leave comments on the ticket and close the ticket without accessing Trac directly and copying what you just sent in the commit message.
+
+Note: Since the move to Mercurial, the commit messages will only appear in the Trac ticket when the changes are merged into the Master repositories. Until this point, the changes aren't incorporated in an 'official' repository.
 
 ==== Adding comments to a ticket ====