| 28 | |
| 29 | |
| 30 | == About Trac&Subversion, code guidelines == |
| 31 | |
| 32 | To allow proper coding and usage of Trac&Subversion features, it is suggested to follow some guidelines. |
| 33 | |
| 34 | First, all commits must belong to a ticket; tickets can be created by project manager or by developers for defect fixing, code enhancements or other tasks. |
| 35 | |
| 36 | Tickets will be used to tell other people about problems, and allow discussion of patches or new code added. |
| 37 | Subversion commits needs to link their ticket in commit message. This can be done using the following syntax: |
| 38 | |
| 39 | {{{ |
| 40 | svn commit -m "Here are my changes. ticket:1." *.* |
| 41 | }}} |
| 42 | |
| 43 | Trac timeline will automagically convert 'ticket:1' into the URL of the ticket. |
| 44 | |
| 45 | At the same time, the changeset number should be added to the ticket using the following syntax: |
| 46 | |
| 47 | {{{ |
| 48 | (changeset:145) Here are my changes. |
| 49 | }}} |
| 50 | |
| 51 | This allows following ticket life without looking at timeline changes every time. While the commit message is usually short, developers can add more detailed informations in ticket record. Remember, other developers could not know what you are doing, or understand what has been changed simply looking at code. |
| 52 | |
| 53 | Also we need to track changes to avoid regressions as much as possible: exhaustive descriptions makes life much easier when regressions or typos must be fixed. |