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