| | 1 | == Commit Policies == |
| | 2 | |
| | 3 | - When you start implementing a new feature, bug fix etc, always do it '''on the top of the main repository''', not on the top of your last local commit. |
| | 4 | - Be very careful not to add unnecessary files (but to add everything that necessary) |
| | 5 | - Do not add generated files into the repository. |
| | 6 | - Do not add test files except very small ones. |
| | 7 | - Make sure that '''{{{make check}}}''' passes without any compilation warning for each commit with {{{g++-4.2}}}. |
| | 8 | - When files are renamed or new ones added also check the changset with '''{{{make distcheck}}}''' |
| | 9 | - At each point, changes should be "clean", i.e. to be self-contained, and not include any changesets that were false starts. |
| | 10 | - If you are working on a more substantial new feature or improvement, you probably want to commit frequently in order to make it possible the revert the changes that turn to be a bad idea later. Feel free to do that, but before you share your changes with others, you should clean your repository by removing the unwanted commits and concatenating those actually belong together. Here is a nice description how to do that: http://www.selenic.com/mercurial/wiki/index.cgi/TipsAndTricks |
| | 11 | - When you add a new algorithm or data structure |
| | 12 | - Take the hassle to write a complete doxygen documentation as well. |
| | 13 | - Place the documentation into an appropriate doxygen module. |
| | 14 | - Also provide an exhaustive test case, whenever it make sense. |
| | 15 | |
| | 16 | == Commit Metainfo == |
| | 17 | User (author) identifier:: |
| | 18 | Use your real name and email address in the following form. |
| | 19 | {{{ |
| | 20 | Winston Churchill <wchurchill@dowling.gov.uk> |
| | 21 | }}} |
| | 22 | Use the same string for all of your commits. |
| | 23 | Commit log:: |
| | 24 | - The first line must be a self containing short '''but meaningful''' summary of the changeset. It should be no longer than 70 character. |
| | 25 | - If a changeset relates to a ticket, please always indicate the corresponding ticket id at the end of the first line of the log message, like {{{(ticket #76)}}} or just {{{(#76)}}}. |
| | 26 | - Then comes a longer description of the changes, if necessary. Do not list the changed files, but instead detail the nature of the changes. |
| | 27 | |
| | 28 | == Uploading Patch to Trac == |
| | 29 | |
| | 30 | - When you upload a patch created from a changeset, please include its hash-id into the file-name. At least specify it in the attachment comment. |
| | 31 | - When referring to a patch in the ticket, please use the hash-id instead of the file-name. (In the usual way, like [8ceb318224b1]). If we do so, it will be immediately visible whether or not the changeset you are talking about is already in the main branch. |
