1<title>Check-in Checklist</title> 2 3<h2><u>Always</u> run the following checklist prior to <u>every</u> 4check-in or commit to the Fossil repository:</h2> 5 6Before every check-in: 7 8 0. <b>fossil user default</b> → your username is correct. 9 10 1. <b>fossil diff</b> → 11 <ol type="a"> 12 <li> No stray changes 13 <li> All changes comply with the license 14 <li> All inputs are scrubbed before use 15 <li> No injection attacks via %s formats 16 </ol> 17 18 2. <b>fossil extra</b> → no unmanaged files need to be added. 19 20 3. The check-in will go onto the desired branch. 21 → Check-ins to trunk normally require approval from 22 the lead programmer (drh). 23 24 4. auto-sync is on, or the system clock is verified 25 26 5. If sources files have been added or removed, ensure all makefiles 27 and configure scripts have been updated accordingly. 28 29Before every check-in to <b>trunk</b>: 30 31 6. No compiler warnings on the development machine. 32 33 7. The fossil executable that results from a build actually works. 34 35 36<hr> 37<h2>Commentary</h2> 38 39Before you go ahead and push content back to the servers, make sure 40that the username you are using by default matches your username 41within the project. Also remember to enable the localauth setting 42if you intend to make changes via a locally served web UI. 43 44Item 1 is the most important step. Consider using <b>gdiff</b> 45instead of <b>diff</b> if you have a graphical differ configured. Or 46use the command-line option <b>--tk</b>. Also consider the <b>-v</b> 47command-line option to show the complete text of newly added files. 48The recommended command for completing checklist item 1 is: 49 50 <b>fossil diff --tk -v</b> 51 52Look carefully at every changed line in item 1. 53Make sure that you are not about to commit unrelated changes. 54If there are two or more unrelated changes present, consider 55breaking up the commit into two or more separate commits. 56Always make 100% sure that all changes are compatible with the 57BSD license, that you have the authority to commit the code in accordance 58with the [/doc/trunk/www/copyright-release.html | CLA] that you have 59signed and have on file, and that 60no NDAs, copyrights, patents, or trademarks are infringed by the check-in. 61Also check very carefully to make sure that 62you are not introducing security vulnerabilities. Pay particular attention 63to the possibility of SQL or HTML injection attacks. 64 65Item 2 verifies that you have not added source files but failed to 66do the necessary "<b>fossil add</b>" to manage them. If you commit 67without bringing the new file under source control, the check-in will 68be broken. That, in turn, can cause complications far in the future 69when we are bisecting for a bug. 70 71For item 3, Run "<b>fossil status</b>" or the equivalent to 72make sure your changes are going into the branch you think they are. 73Also double-check the branch name when entering change comments. 74Never check into trunk unless you are expressly authorized to do so. 75 76For Item 4, if you are on-network, make sure auto-sync is enabled. This 77will minimize the risk of an unintended fork. It will also give you a 78warning if you system clock is set incorrectly. If you are off-network, 79make sure that your system clock is correct or at least close to correct 80so that your check-in does not appear out-of-sequence on timelines. 81On-network commits are preferred, especially for trunk commits. 82 83Items 6 and 7 help to ensure that check-ins on the trunk always work. 84Knowing that the trunk always works makes bisecting much easier. Items 856 and 7 are recommended for all check-ins, even those that are on a branch. 86But they are especially important for trunk check-ins. We desire that 87all trunk check-ins work at all times. Any experimental, unstable, or 88questionable changes should go on a branch and be merged into trunk after 89further testing. 90