|
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
|
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
|
|
|
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
|
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
|
use the command-line option <b>--tk</b>. Also consider the <b>-v</b> |
|
47
|
command-line option to show the complete text of newly added files. |
|
48
|
The recommended command for completing checklist item 1 is: |
|
49
|
|
|
50
|
<b>fossil diff --tk -v</b> |
|
51
|
|
|
52
|
Look carefully at every changed line in item 1. |
|
53
|
Make sure that you are not about to commit unrelated changes. |
|
54
|
If there are two or more unrelated changes present, consider |
|
55
|
breaking up the commit into two or more separate commits. |
|
56
|
Always make 100% sure that all changes are compatible with the |
|
57
|
BSD license, that you have the authority to commit the code in accordance |
|
58
|
with the [/doc/trunk/www/copyright-release.html | CLA] that you have |
|
59
|
signed and have on file, and that |
|
60
|
no NDAs, copyrights, patents, or trademarks are infringed by the check-in. |
|
61
|
Also check very carefully to make sure that |
|
62
|
you are not introducing security vulnerabilities. Pay particular attention |
|
63
|
to the possibility of SQL or HTML injection attacks. |
|
64
|
|
|
65
|
Item 2 verifies that you have not added source files but failed to |
|
66
|
do the necessary "<b>fossil add</b>" to manage them. If you commit |
|
67
|
without bringing the new file under source control, the check-in will |
|
68
|
be broken. That, in turn, can cause complications far in the future |
|
69
|
when we are bisecting for a bug. |
|
70
|
|
|
71
|
For item 3, Run "<b>fossil status</b>" or the equivalent to |
|
72
|
make sure your changes are going into the branch you think they are. |
|
73
|
Also double-check the branch name when entering change comments. |
|
74
|
Never check into trunk unless you are expressly authorized to do so. |
|
75
|
|
|
76
|
For Item 4, if you are on-network, make sure auto-sync is enabled. This |
|
77
|
will minimize the risk of an unintended fork. It will also give you a |
|
78
|
warning if you system clock is set incorrectly. If you are off-network, |
|
79
|
make sure that your system clock is correct or at least close to correct |
|
80
|
so that your check-in does not appear out-of-sequence on timelines. |
|
81
|
On-network commits are preferred, especially for trunk commits. |
|
82
|
|
|
83
|
Items 6 and 7 help to ensure that check-ins on the trunk always work. |
|
84
|
Knowing that the trunk always works makes bisecting much easier. Items |
|
85
|
6 and 7 are recommended for all check-ins, even those that are on a branch. |
|
86
|
But they are especially important for trunk check-ins. We desire that |
|
87
|
all trunk check-ins work at all times. Any experimental, unstable, or |
|
88
|
questionable changes should go on a branch and be merged into trunk after |
|
89
|
further testing. |
|
90
|
|