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