Fossil SCM
catch up with trunk & fix commentary portion of checkin.wiki.
Commit
35e33287348cf8e36f302407565e7fd11ce71706
Parent
a1f3987760b9406…
8 files changed
+1
-1
+1
-1
+11
-5
+24
-3
+6
-2
+2
-1
+16
-16
+16
-16
+1
-1
| --- src/blob.c | ||
| +++ src/blob.c | ||
| @@ -120,11 +120,11 @@ | ||
| 120 | 120 | ** This routine is called if a blob operation fails because we |
| 121 | 121 | ** have run out of memory. |
| 122 | 122 | */ |
| 123 | 123 | static void blob_panic(void){ |
| 124 | 124 | static const char zErrMsg[] = "out of memory\n"; |
| 125 | - write(2, zErrMsg, sizeof(zErrMsg)-1); | |
| 125 | + fputs(zErrMsg, stderr); | |
| 126 | 126 | fossil_exit(1); |
| 127 | 127 | } |
| 128 | 128 | |
| 129 | 129 | /* |
| 130 | 130 | ** A reallocation function that assumes that aData came from malloc(). |
| 131 | 131 |
| --- src/blob.c | |
| +++ src/blob.c | |
| @@ -120,11 +120,11 @@ | |
| 120 | ** This routine is called if a blob operation fails because we |
| 121 | ** have run out of memory. |
| 122 | */ |
| 123 | static void blob_panic(void){ |
| 124 | static const char zErrMsg[] = "out of memory\n"; |
| 125 | write(2, zErrMsg, sizeof(zErrMsg)-1); |
| 126 | fossil_exit(1); |
| 127 | } |
| 128 | |
| 129 | /* |
| 130 | ** A reallocation function that assumes that aData came from malloc(). |
| 131 |
| --- src/blob.c | |
| +++ src/blob.c | |
| @@ -120,11 +120,11 @@ | |
| 120 | ** This routine is called if a blob operation fails because we |
| 121 | ** have run out of memory. |
| 122 | */ |
| 123 | static void blob_panic(void){ |
| 124 | static const char zErrMsg[] = "out of memory\n"; |
| 125 | fputs(zErrMsg, stderr); |
| 126 | fossil_exit(1); |
| 127 | } |
| 128 | |
| 129 | /* |
| 130 | ** A reallocation function that assumes that aData came from malloc(). |
| 131 |
+1
-1
| --- src/branch.c | ||
| +++ src/branch.c | ||
| @@ -174,11 +174,11 @@ | ||
| 174 | 174 | |
| 175 | 175 | /* Commit */ |
| 176 | 176 | db_end_transaction(0); |
| 177 | 177 | |
| 178 | 178 | /* Do an autosync push, if requested */ |
| 179 | - autosync(AUTOSYNC_PUSH); | |
| 179 | + if( !isPrivate ) autosync(AUTOSYNC_PUSH); | |
| 180 | 180 | } |
| 181 | 181 | |
| 182 | 182 | /* |
| 183 | 183 | ** Prepare a query that will list all branches. |
| 184 | 184 | */ |
| 185 | 185 |
| --- src/branch.c | |
| +++ src/branch.c | |
| @@ -174,11 +174,11 @@ | |
| 174 | |
| 175 | /* Commit */ |
| 176 | db_end_transaction(0); |
| 177 | |
| 178 | /* Do an autosync push, if requested */ |
| 179 | autosync(AUTOSYNC_PUSH); |
| 180 | } |
| 181 | |
| 182 | /* |
| 183 | ** Prepare a query that will list all branches. |
| 184 | */ |
| 185 |
| --- src/branch.c | |
| +++ src/branch.c | |
| @@ -174,11 +174,11 @@ | |
| 174 | |
| 175 | /* Commit */ |
| 176 | db_end_transaction(0); |
| 177 | |
| 178 | /* Do an autosync push, if requested */ |
| 179 | if( !isPrivate ) autosync(AUTOSYNC_PUSH); |
| 180 | } |
| 181 | |
| 182 | /* |
| 183 | ** Prepare a query that will list all branches. |
| 184 | */ |
| 185 |
+11
-5
| --- src/cgi.c | ||
| +++ src/cgi.c | ||
| @@ -1153,11 +1153,13 @@ | ||
| 1153 | 1153 | fossil_print("Listening for HTTP requests on TCP port %d\n", iPort); |
| 1154 | 1154 | fflush(stdout); |
| 1155 | 1155 | } |
| 1156 | 1156 | if( zBrowser ){ |
| 1157 | 1157 | zBrowser = mprintf(zBrowser, iPort); |
| 1158 | - system(zBrowser); | |
| 1158 | + if( system(zBrowser)<0 ){ | |
| 1159 | + fossil_warning("cannot start browser: %s\n", zBrowser); | |
| 1160 | + } | |
| 1159 | 1161 | } |
| 1160 | 1162 | while( 1 ){ |
| 1161 | 1163 | if( nchildren>MAX_PARALLEL ){ |
| 1162 | 1164 | /* Slow down if connections are arriving too fast */ |
| 1163 | 1165 | sleep( nchildren-MAX_PARALLEL ); |
| @@ -1174,20 +1176,24 @@ | ||
| 1174 | 1176 | child = fork(); |
| 1175 | 1177 | if( child!=0 ){ |
| 1176 | 1178 | if( child>0 ) nchildren++; |
| 1177 | 1179 | close(connection); |
| 1178 | 1180 | }else{ |
| 1181 | + int nErr = 0, fd; | |
| 1179 | 1182 | close(0); |
| 1180 | - dup(connection); | |
| 1183 | + fd = dup(connection); | |
| 1184 | + if( fd!=0 ) nErr++; | |
| 1181 | 1185 | close(1); |
| 1182 | - dup(connection); | |
| 1186 | + fd = dup(connection); | |
| 1187 | + if( fd!=1 ) nErr++; | |
| 1183 | 1188 | if( !g.fHttpTrace && !g.fSqlTrace ){ |
| 1184 | 1189 | close(2); |
| 1185 | - dup(connection); | |
| 1190 | + fd = dup(connection); | |
| 1191 | + if( fd!=2 ) nErr++; | |
| 1186 | 1192 | } |
| 1187 | 1193 | close(connection); |
| 1188 | - return 0; | |
| 1194 | + return nErr; | |
| 1189 | 1195 | } |
| 1190 | 1196 | } |
| 1191 | 1197 | } |
| 1192 | 1198 | /* Bury dead children */ |
| 1193 | 1199 | while( waitpid(0, 0, WNOHANG)>0 ){ |
| 1194 | 1200 |
| --- src/cgi.c | |
| +++ src/cgi.c | |
| @@ -1153,11 +1153,13 @@ | |
| 1153 | fossil_print("Listening for HTTP requests on TCP port %d\n", iPort); |
| 1154 | fflush(stdout); |
| 1155 | } |
| 1156 | if( zBrowser ){ |
| 1157 | zBrowser = mprintf(zBrowser, iPort); |
| 1158 | system(zBrowser); |
| 1159 | } |
| 1160 | while( 1 ){ |
| 1161 | if( nchildren>MAX_PARALLEL ){ |
| 1162 | /* Slow down if connections are arriving too fast */ |
| 1163 | sleep( nchildren-MAX_PARALLEL ); |
| @@ -1174,20 +1176,24 @@ | |
| 1174 | child = fork(); |
| 1175 | if( child!=0 ){ |
| 1176 | if( child>0 ) nchildren++; |
| 1177 | close(connection); |
| 1178 | }else{ |
| 1179 | close(0); |
| 1180 | dup(connection); |
| 1181 | close(1); |
| 1182 | dup(connection); |
| 1183 | if( !g.fHttpTrace && !g.fSqlTrace ){ |
| 1184 | close(2); |
| 1185 | dup(connection); |
| 1186 | } |
| 1187 | close(connection); |
| 1188 | return 0; |
| 1189 | } |
| 1190 | } |
| 1191 | } |
| 1192 | /* Bury dead children */ |
| 1193 | while( waitpid(0, 0, WNOHANG)>0 ){ |
| 1194 |
| --- src/cgi.c | |
| +++ src/cgi.c | |
| @@ -1153,11 +1153,13 @@ | |
| 1153 | fossil_print("Listening for HTTP requests on TCP port %d\n", iPort); |
| 1154 | fflush(stdout); |
| 1155 | } |
| 1156 | if( zBrowser ){ |
| 1157 | zBrowser = mprintf(zBrowser, iPort); |
| 1158 | if( system(zBrowser)<0 ){ |
| 1159 | fossil_warning("cannot start browser: %s\n", zBrowser); |
| 1160 | } |
| 1161 | } |
| 1162 | while( 1 ){ |
| 1163 | if( nchildren>MAX_PARALLEL ){ |
| 1164 | /* Slow down if connections are arriving too fast */ |
| 1165 | sleep( nchildren-MAX_PARALLEL ); |
| @@ -1174,20 +1176,24 @@ | |
| 1176 | child = fork(); |
| 1177 | if( child!=0 ){ |
| 1178 | if( child>0 ) nchildren++; |
| 1179 | close(connection); |
| 1180 | }else{ |
| 1181 | int nErr = 0, fd; |
| 1182 | close(0); |
| 1183 | fd = dup(connection); |
| 1184 | if( fd!=0 ) nErr++; |
| 1185 | close(1); |
| 1186 | fd = dup(connection); |
| 1187 | if( fd!=1 ) nErr++; |
| 1188 | if( !g.fHttpTrace && !g.fSqlTrace ){ |
| 1189 | close(2); |
| 1190 | fd = dup(connection); |
| 1191 | if( fd!=2 ) nErr++; |
| 1192 | } |
| 1193 | close(connection); |
| 1194 | return nErr; |
| 1195 | } |
| 1196 | } |
| 1197 | } |
| 1198 | /* Bury dead children */ |
| 1199 | while( waitpid(0, 0, WNOHANG)>0 ){ |
| 1200 |
M
src/db.c
+24
-3
| --- src/db.c | ||
| +++ src/db.c | ||
| @@ -1407,15 +1407,30 @@ | ||
| 1407 | 1407 | ** .fossil-settings/<name> , and emits warnings if necessary. |
| 1408 | 1408 | ** Returns the non-versioned value without modification if there is no |
| 1409 | 1409 | ** versioned value. |
| 1410 | 1410 | */ |
| 1411 | 1411 | static char *db_get_do_versionable(const char *zName, char *zNonVersionedSetting){ |
| 1412 | - /* Attempt to load the versioned setting from a checked out file */ | |
| 1413 | 1412 | char *zVersionedSetting = 0; |
| 1414 | 1413 | int noWarn = 0; |
| 1415 | - | |
| 1416 | - if( db_open_local() ){ | |
| 1414 | + struct _cacheEntry { | |
| 1415 | + struct _cacheEntry *next; | |
| 1416 | + const char *zName, *zValue; | |
| 1417 | + } *cacheEntry = 0; | |
| 1418 | + static struct _cacheEntry *cache = 0; | |
| 1419 | + | |
| 1420 | + /* Look up name in cache */ | |
| 1421 | + cacheEntry = cache; | |
| 1422 | + while( cacheEntry!=0 ){ | |
| 1423 | + if( fossil_strcmp(cacheEntry->zName, zName)==0 ){ | |
| 1424 | + zVersionedSetting = fossil_strdup(cacheEntry->zValue); | |
| 1425 | + break; | |
| 1426 | + } | |
| 1427 | + cacheEntry = cacheEntry->next; | |
| 1428 | + } | |
| 1429 | + /* Attempt to read value from file in checkout if there wasn't a cache hit | |
| 1430 | + ** and a checkout is open. */ | |
| 1431 | + if( cacheEntry==0 && db_open_local() ){ | |
| 1417 | 1432 | Blob versionedPathname; |
| 1418 | 1433 | char *zVersionedPathname; |
| 1419 | 1434 | blob_zero(&versionedPathname); |
| 1420 | 1435 | blob_appendf(&versionedPathname, "%s/.fossil-settings/%s", |
| 1421 | 1436 | g.zLocalRoot, zName); |
| @@ -1436,10 +1451,16 @@ | ||
| 1436 | 1451 | if( file_size(blob_str(&versionedPathname))>=0 ){ |
| 1437 | 1452 | noWarn = 1; |
| 1438 | 1453 | } |
| 1439 | 1454 | } |
| 1440 | 1455 | blob_reset(&versionedPathname); |
| 1456 | + /* Store result in cache, which can be the value or 0 if not found */ | |
| 1457 | + cacheEntry = (struct _cacheEntry*)fossil_malloc(sizeof(struct _cacheEntry)); | |
| 1458 | + cacheEntry->next = cache; | |
| 1459 | + cacheEntry->zName = zName; | |
| 1460 | + cacheEntry->zValue = fossil_strdup(zVersionedSetting); | |
| 1461 | + cache = cacheEntry; | |
| 1441 | 1462 | } |
| 1442 | 1463 | /* Display a warning? */ |
| 1443 | 1464 | if( zVersionedSetting!=0 && zNonVersionedSetting!=0 |
| 1444 | 1465 | && zNonVersionedSetting[0]!='\0' && !noWarn |
| 1445 | 1466 | ){ |
| 1446 | 1467 |
| --- src/db.c | |
| +++ src/db.c | |
| @@ -1407,15 +1407,30 @@ | |
| 1407 | ** .fossil-settings/<name> , and emits warnings if necessary. |
| 1408 | ** Returns the non-versioned value without modification if there is no |
| 1409 | ** versioned value. |
| 1410 | */ |
| 1411 | static char *db_get_do_versionable(const char *zName, char *zNonVersionedSetting){ |
| 1412 | /* Attempt to load the versioned setting from a checked out file */ |
| 1413 | char *zVersionedSetting = 0; |
| 1414 | int noWarn = 0; |
| 1415 | |
| 1416 | if( db_open_local() ){ |
| 1417 | Blob versionedPathname; |
| 1418 | char *zVersionedPathname; |
| 1419 | blob_zero(&versionedPathname); |
| 1420 | blob_appendf(&versionedPathname, "%s/.fossil-settings/%s", |
| 1421 | g.zLocalRoot, zName); |
| @@ -1436,10 +1451,16 @@ | |
| 1436 | if( file_size(blob_str(&versionedPathname))>=0 ){ |
| 1437 | noWarn = 1; |
| 1438 | } |
| 1439 | } |
| 1440 | blob_reset(&versionedPathname); |
| 1441 | } |
| 1442 | /* Display a warning? */ |
| 1443 | if( zVersionedSetting!=0 && zNonVersionedSetting!=0 |
| 1444 | && zNonVersionedSetting[0]!='\0' && !noWarn |
| 1445 | ){ |
| 1446 |
| --- src/db.c | |
| +++ src/db.c | |
| @@ -1407,15 +1407,30 @@ | |
| 1407 | ** .fossil-settings/<name> , and emits warnings if necessary. |
| 1408 | ** Returns the non-versioned value without modification if there is no |
| 1409 | ** versioned value. |
| 1410 | */ |
| 1411 | static char *db_get_do_versionable(const char *zName, char *zNonVersionedSetting){ |
| 1412 | char *zVersionedSetting = 0; |
| 1413 | int noWarn = 0; |
| 1414 | struct _cacheEntry { |
| 1415 | struct _cacheEntry *next; |
| 1416 | const char *zName, *zValue; |
| 1417 | } *cacheEntry = 0; |
| 1418 | static struct _cacheEntry *cache = 0; |
| 1419 | |
| 1420 | /* Look up name in cache */ |
| 1421 | cacheEntry = cache; |
| 1422 | while( cacheEntry!=0 ){ |
| 1423 | if( fossil_strcmp(cacheEntry->zName, zName)==0 ){ |
| 1424 | zVersionedSetting = fossil_strdup(cacheEntry->zValue); |
| 1425 | break; |
| 1426 | } |
| 1427 | cacheEntry = cacheEntry->next; |
| 1428 | } |
| 1429 | /* Attempt to read value from file in checkout if there wasn't a cache hit |
| 1430 | ** and a checkout is open. */ |
| 1431 | if( cacheEntry==0 && db_open_local() ){ |
| 1432 | Blob versionedPathname; |
| 1433 | char *zVersionedPathname; |
| 1434 | blob_zero(&versionedPathname); |
| 1435 | blob_appendf(&versionedPathname, "%s/.fossil-settings/%s", |
| 1436 | g.zLocalRoot, zName); |
| @@ -1436,10 +1451,16 @@ | |
| 1451 | if( file_size(blob_str(&versionedPathname))>=0 ){ |
| 1452 | noWarn = 1; |
| 1453 | } |
| 1454 | } |
| 1455 | blob_reset(&versionedPathname); |
| 1456 | /* Store result in cache, which can be the value or 0 if not found */ |
| 1457 | cacheEntry = (struct _cacheEntry*)fossil_malloc(sizeof(struct _cacheEntry)); |
| 1458 | cacheEntry->next = cache; |
| 1459 | cacheEntry->zName = zName; |
| 1460 | cacheEntry->zValue = fossil_strdup(zVersionedSetting); |
| 1461 | cache = cacheEntry; |
| 1462 | } |
| 1463 | /* Display a warning? */ |
| 1464 | if( zVersionedSetting!=0 && zNonVersionedSetting!=0 |
| 1465 | && zNonVersionedSetting[0]!='\0' && !noWarn |
| 1466 | ){ |
| 1467 |
+6
-2
| --- src/popen.c | ||
| +++ src/popen.c | ||
| @@ -172,17 +172,21 @@ | ||
| 172 | 172 | close(pout[1]); |
| 173 | 173 | *pChildPid = 0; |
| 174 | 174 | return 1; |
| 175 | 175 | } |
| 176 | 176 | if( *pChildPid==0 ){ |
| 177 | + int fd; | |
| 178 | + int nErr = 0; | |
| 177 | 179 | /* This is the child process */ |
| 178 | 180 | close(0); |
| 179 | - dup(pout[0]); | |
| 181 | + fd = dup(pout[0]); | |
| 182 | + if( fd!=0 ) nErr++; | |
| 180 | 183 | close(pout[0]); |
| 181 | 184 | close(pout[1]); |
| 182 | 185 | close(1); |
| 183 | - dup(pin[1]); | |
| 186 | + fd = dup(pin[1]); | |
| 187 | + if( fd!=1 ) nErr++; | |
| 184 | 188 | close(pin[0]); |
| 185 | 189 | close(pin[1]); |
| 186 | 190 | execl("/bin/sh", "/bin/sh", "-c", zCmd, (char*)0); |
| 187 | 191 | return 1; |
| 188 | 192 | }else{ |
| 189 | 193 |
| --- src/popen.c | |
| +++ src/popen.c | |
| @@ -172,17 +172,21 @@ | |
| 172 | close(pout[1]); |
| 173 | *pChildPid = 0; |
| 174 | return 1; |
| 175 | } |
| 176 | if( *pChildPid==0 ){ |
| 177 | /* This is the child process */ |
| 178 | close(0); |
| 179 | dup(pout[0]); |
| 180 | close(pout[0]); |
| 181 | close(pout[1]); |
| 182 | close(1); |
| 183 | dup(pin[1]); |
| 184 | close(pin[0]); |
| 185 | close(pin[1]); |
| 186 | execl("/bin/sh", "/bin/sh", "-c", zCmd, (char*)0); |
| 187 | return 1; |
| 188 | }else{ |
| 189 |
| --- src/popen.c | |
| +++ src/popen.c | |
| @@ -172,17 +172,21 @@ | |
| 172 | close(pout[1]); |
| 173 | *pChildPid = 0; |
| 174 | return 1; |
| 175 | } |
| 176 | if( *pChildPid==0 ){ |
| 177 | int fd; |
| 178 | int nErr = 0; |
| 179 | /* This is the child process */ |
| 180 | close(0); |
| 181 | fd = dup(pout[0]); |
| 182 | if( fd!=0 ) nErr++; |
| 183 | close(pout[0]); |
| 184 | close(pout[1]); |
| 185 | close(1); |
| 186 | fd = dup(pin[1]); |
| 187 | if( fd!=1 ) nErr++; |
| 188 | close(pin[0]); |
| 189 | close(pin[1]); |
| 190 | execl("/bin/sh", "/bin/sh", "-c", zCmd, (char*)0); |
| 191 | return 1; |
| 192 | }else{ |
| 193 |
+2
-1
| --- src/timeline.c | ||
| +++ src/timeline.c | ||
| @@ -1081,11 +1081,12 @@ | ||
| 1081 | 1081 | }else if( zType[0]=='e' ){ |
| 1082 | 1082 | zEType = "event"; |
| 1083 | 1083 | } |
| 1084 | 1084 | } |
| 1085 | 1085 | if( zUser ){ |
| 1086 | - blob_appendf(&sql, " AND event.user=%Q", zUser); | |
| 1086 | + blob_appendf(&sql, " AND (event.user=%Q OR event.euser=%Q)", | |
| 1087 | + zUser, zUser); | |
| 1087 | 1088 | url_add_parameter(&url, "u", zUser); |
| 1088 | 1089 | zThisUser = zUser; |
| 1089 | 1090 | } |
| 1090 | 1091 | if ( zSearch ){ |
| 1091 | 1092 | blob_appendf(&sql, |
| 1092 | 1093 |
| --- src/timeline.c | |
| +++ src/timeline.c | |
| @@ -1081,11 +1081,12 @@ | |
| 1081 | }else if( zType[0]=='e' ){ |
| 1082 | zEType = "event"; |
| 1083 | } |
| 1084 | } |
| 1085 | if( zUser ){ |
| 1086 | blob_appendf(&sql, " AND event.user=%Q", zUser); |
| 1087 | url_add_parameter(&url, "u", zUser); |
| 1088 | zThisUser = zUser; |
| 1089 | } |
| 1090 | if ( zSearch ){ |
| 1091 | blob_appendf(&sql, |
| 1092 |
| --- src/timeline.c | |
| +++ src/timeline.c | |
| @@ -1081,11 +1081,12 @@ | |
| 1081 | }else if( zType[0]=='e' ){ |
| 1082 | zEType = "event"; |
| 1083 | } |
| 1084 | } |
| 1085 | if( zUser ){ |
| 1086 | blob_appendf(&sql, " AND (event.user=%Q OR event.euser=%Q)", |
| 1087 | zUser, zUser); |
| 1088 | url_add_parameter(&url, "u", zUser); |
| 1089 | zThisUser = zUser; |
| 1090 | } |
| 1091 | if ( zSearch ){ |
| 1092 | blob_appendf(&sql, |
| 1093 |
+16
-16
| --- 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 | - 0. <b>fossil user default</b> → you are indeed using your | |
| 9 | - assigned username. | |
| 10 | - 1. <b>fossil diff</b> → | |
| 8 | + 1. <b>fossil user default</b> → your username is correct. | |
| 9 | + | |
| 10 | + 2. <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 | - 2. <b>fossil extra</b> → no unmanaged files need to be added. | |
| 18 | + 3. <b>fossil extra</b> → no unmanaged files need to be added. | |
| 19 | 19 | |
| 20 | - 3. The check-in will go onto the desired branch. | |
| 20 | + 4. 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 | - 4. auto-sync is on, or the system clock is verified | |
| 24 | + 5. auto-sync is on, or the system clock is verified | |
| 25 | 25 | |
| 26 | - 5. If sources files have been added or removed, ensure all makefiles | |
| 26 | + 6. 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 | - 6. No compiler warnings on the development machine. | |
| 31 | + 7. No compiler warnings on the development machine. | |
| 32 | 32 | |
| 33 | - 7. The fossil executable that results from a build actually works. | |
| 33 | + 8. 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 1 is the most important step. Consider using <b>gdiff</b> | |
| 44 | +Item 2 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 1. | |
| 48 | +Look carefully at every changed line in item 2. | |
| 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 2 verifies that you have not added source files but failed to | |
| 61 | +Item 3 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 3, Run "<b>fossil status</b>" or the equivalent to | |
| 67 | +For item 4, 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 4, if you are on-network, make sure auto-sync is enabled. This | |
| 72 | +For Item 5, 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 6 and 7 help to ensure that check-ins on the trunk always work. | |
| 79 | +Items 7 and 8 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 | -6 and 7 are recommended for all check-ins, even those that are on a branch. | |
| 81 | +7 and 8 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 | 0. <b>fossil user default</b> → you are indeed using your |
| 9 | assigned username. |
| 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 |
| --- 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 |
+16
-16
| --- 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 | - 0. <b>fossil user default</b> → you are indeed using your | |
| 9 | - assigned username. | |
| 10 | - 1. <b>fossil diff</b> → | |
| 8 | + 1. <b>fossil user default</b> → your username is correct. | |
| 9 | + | |
| 10 | + 2. <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 | - 2. <b>fossil extra</b> → no unmanaged files need to be added. | |
| 18 | + 3. <b>fossil extra</b> → no unmanaged files need to be added. | |
| 19 | 19 | |
| 20 | - 3. The check-in will go onto the desired branch. | |
| 20 | + 4. 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 | - 4. auto-sync is on, or the system clock is verified | |
| 24 | + 5. auto-sync is on, or the system clock is verified | |
| 25 | 25 | |
| 26 | - 5. If sources files have been added or removed, ensure all makefiles | |
| 26 | + 6. 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 | - 6. No compiler warnings on the development machine. | |
| 31 | + 7. No compiler warnings on the development machine. | |
| 32 | 32 | |
| 33 | - 7. The fossil executable that results from a build actually works. | |
| 33 | + 8. 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 1 is the most important step. Consider using <b>gdiff</b> | |
| 44 | +Item 2 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 1. | |
| 48 | +Look carefully at every changed line in item 2. | |
| 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 2 verifies that you have not added source files but failed to | |
| 61 | +Item 3 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 3, Run "<b>fossil status</b>" or the equivalent to | |
| 67 | +For item 4, 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 4, if you are on-network, make sure auto-sync is enabled. This | |
| 72 | +For Item 5, 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 6 and 7 help to ensure that check-ins on the trunk always work. | |
| 79 | +Items 7 and 8 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 | -6 and 7 are recommended for all check-ins, even those that are on a branch. | |
| 81 | +7 and 8 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 | 0. <b>fossil user default</b> → you are indeed using your |
| 9 | assigned username. |
| 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 |
| --- 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 |