Fossil

Check-in [90e310eb]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Change numbering back so that the preliminary step is 0, the most important one is #1.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | msw-hack
Files: files | file ages | folders
SHA1: 90e310ebbdef2c15719d8804fdc748514b3b49a2
User & Date: martin.weber 2011-08-23 17:57:36
Context
2011-09-06
20:12
catch up with trunk. Remove C++ style comments from http_ssl.c. check-in: 0f1c41bc user: martin.weber tags: msw-hack
2011-08-23
18:00
go back to the old numbering on the pre-checkin checklist (ok'd drh). check-in: a87717ad user: martin.weber tags: trunk
17:57
Change numbering back so that the preliminary step is 0, the most important one is #1. check-in: 90e310eb user: martin.weber tags: msw-hack
17:23
catch up with trunk & fix commentary portion of checkin.wiki. check-in: 35e33287 user: martin.weber tags: msw-hack
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/checkin.wiki.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<title>Check-in Checklist</title>

<h2><u>Always</u> run the following checklist prior to <u>every</u>
check-in or commit to the Fossil repository:</h2>

Before every check-in:

  1.   <b>fossil user default</b> &rarr; your username is correct.

  2.   <b>fossil diff</b> &rarr;
       <ol type="a">
       <li> No stray changes
       <li> All changes comply with the license
       <li> All inputs are scrubbed before use
       <li> No injection attacks via %s formats
       </ol>

  3.   <b>fossil extra</b> &rarr; no unmanaged files need to be added.

  4.   The check-in will go onto the desired branch.
       &rarr;  Do <u>not</u> check into trunk without prior approval from
       the lead programmer (drh)!

  5.   auto-sync is on, or the system clock is verified

  6.   If sources files have been added or removed, ensure all makefiles
       and configure scripts have been updated accordingly.

Before every check-in to <b>trunk</b>:

  7.   No compiler warnings on the development machine.

  8.   The fossil executable that results from a build actually works.


<hr>
<h2>Commentary</h2>

Before you go ahead and push content back to the servers, make sure
that the username you are using by default matches your username
within the project. Also remember to enable the localauth setting
if you intend to make changes via a locally served web UI.

Item 2 is the most important step.  Consider using <b>gdiff</b>
instead of <b>diff</b> if you have a graphical differ configured.  Or,
pipe the output of "<b>fossil diff</b>" into "<b>open -f</b>" (on a mac) to
get the diff output in a separate text window for easier viewing.
Look carefully at every changed line in item 2.
Make sure that you are not about to commit unrelated changes.
If there are two or more unrelated changes present, consider
breaking up the commit into two or more separate commits.
Always make 100% sure that all changes are compatible with the
BSD license, that you have the authority to commit the code in accordance
with the [/doc/trunk/www/copyright-release.html | CLA] that you have
signed and have on file, and that
no NDAs, copyrights, patents, or trademarks are infringed by the check-in.
Also check very carefully to make sure that
you are not introducing security vulnerabilities.  Pay particular attention
to the possibility of SQL or HTML injection attacks.

Item 3 verifies that you have not added source files but failed to
do the necessary "<b>fossil add</b>" to manage them.  If you commit
without bringing the new file under source control, the check-in will
be broken.  That, in turn, can cause complications far in the future
when we are bisecting for a bug.

For item 4, Run "<b>fossil status</b>" or the equivalent to
make sure your changes are going into the branch you think they are.
Also double-check the branch name when entering change comments.
Never check into trunk unless you are expressly authorized to do so.

For Item 5, if you are on-network, make sure auto-sync is enabled.  This
will minimize the risk of an unintended fork.  It will also give you a
warning if you system clock is set incorrectly.  If you are off-network,
make sure that your system clock is correct or at least close to correct
so that your check-in does not appear out-of-sequence on timelines.
On-network commits are preferred, especially for trunk commits.

Items 7 and 8 help to ensure that check-ins on the trunk always work.
Knowing that the trunk always works makes bisecting much easier.  Items
7 and 8 are recommended for all check-ins, even those that are on a branch.
But they are especially important for trunk check-ins.  We desire that
all trunk check-ins work at all times.  Any experimental, unstable, or
questionable changes should go on a branch and be merged into trunk after
further testing.







|

|







|

|



|

|




|

|










|



|












|





|




|






|

|




1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
<title>Check-in Checklist</title>

<h2><u>Always</u> run the following checklist prior to <u>every</u>
check-in or commit to the Fossil repository:</h2>

Before every check-in:

  0.   <b>fossil user default</b> &rarr; your username is correct.

  1.   <b>fossil diff</b> &rarr;
       <ol type="a">
       <li> No stray changes
       <li> All changes comply with the license
       <li> All inputs are scrubbed before use
       <li> No injection attacks via %s formats
       </ol>

  2.   <b>fossil extra</b> &rarr; no unmanaged files need to be added.

  3.   The check-in will go onto the desired branch.
       &rarr;  Do <u>not</u> check into trunk without prior approval from
       the lead programmer (drh)!

  4.   auto-sync is on, or the system clock is verified

  5.   If sources files have been added or removed, ensure all makefiles
       and configure scripts have been updated accordingly.

Before every check-in to <b>trunk</b>:

  6.   No compiler warnings on the development machine.

  7.   The fossil executable that results from a build actually works.


<hr>
<h2>Commentary</h2>

Before you go ahead and push content back to the servers, make sure
that the username you are using by default matches your username
within the project. Also remember to enable the localauth setting
if you intend to make changes via a locally served web UI.

Item 1 is the most important step.  Consider using <b>gdiff</b>
instead of <b>diff</b> if you have a graphical differ configured.  Or,
pipe the output of "<b>fossil diff</b>" into "<b>open -f</b>" (on a mac) to
get the diff output in a separate text window for easier viewing.
Look carefully at every changed line in item 1.
Make sure that you are not about to commit unrelated changes.
If there are two or more unrelated changes present, consider
breaking up the commit into two or more separate commits.
Always make 100% sure that all changes are compatible with the
BSD license, that you have the authority to commit the code in accordance
with the [/doc/trunk/www/copyright-release.html | CLA] that you have
signed and have on file, and that
no NDAs, copyrights, patents, or trademarks are infringed by the check-in.
Also check very carefully to make sure that
you are not introducing security vulnerabilities.  Pay particular attention
to the possibility of SQL or HTML injection attacks.

Item 2 verifies that you have not added source files but failed to
do the necessary "<b>fossil add</b>" to manage them.  If you commit
without bringing the new file under source control, the check-in will
be broken.  That, in turn, can cause complications far in the future
when we are bisecting for a bug.

For item 3, Run "<b>fossil status</b>" or the equivalent to
make sure your changes are going into the branch you think they are.
Also double-check the branch name when entering change comments.
Never check into trunk unless you are expressly authorized to do so.

For Item 4, if you are on-network, make sure auto-sync is enabled.  This
will minimize the risk of an unintended fork.  It will also give you a
warning if you system clock is set incorrectly.  If you are off-network,
make sure that your system clock is correct or at least close to correct
so that your check-in does not appear out-of-sequence on timelines.
On-network commits are preferred, especially for trunk commits.

Items 6 and 7 help to ensure that check-ins on the trunk always work.
Knowing that the trunk always works makes bisecting much easier.  Items
6 and 7 are recommended for all check-ins, even those that are on a branch.
But they are especially important for trunk check-ins.  We desire that
all trunk check-ins work at all times.  Any experimental, unstable, or
questionable changes should go on a branch and be merged into trunk after
further testing.