Fossil SCM
Update custom makefile. Remove some unnecessary spacing in documentation
Commit
e2751b18af7fdae65992f63998be4b429e8a11f55153012e1686396eb6412105
Parent
b2c424ada85ed83…
11 files changed
+2
-2
+12
+2
-2
+8
-8
+1
-1
+7
-7
+1
-1
+2
-2
+1
-1
+2
-2
+10
-10
+2
-2
| --- Makefile.osx-jaguar | ||
| +++ Makefile.osx-jaguar | ||
| @@ -38,11 +38,11 @@ | ||
| 38 | 38 | BCCFLAGS = $(CFLAGS) |
| 39 | 39 | |
| 40 | 40 | #### The suffix to add to final executable file. When cross-compiling |
| 41 | 41 | # to windows, make this ".exe". Otherwise leave it blank. |
| 42 | 42 | # |
| 43 | -E = | |
| 43 | +E = | |
| 44 | 44 | |
| 45 | 45 | TCC = cc |
| 46 | 46 | TCCFLAGS = $(CFLAGS) |
| 47 | 47 | |
| 48 | 48 | #### Tcl shell for use in running the fossil testsuite. If you do not |
| @@ -59,15 +59,15 @@ | ||
| 59 | 59 | TCC += -DWITHOUT_ICONV |
| 60 | 60 | TCC += -Dsocklen_t=int |
| 61 | 61 | TCC += -DSQLITE_MAX_MMAP_SIZE=0 |
| 62 | 62 | TCC += -DFOSSIL_ENABLE_LEGACY_MV_RM=1 |
| 63 | 63 | INSTALLDIR = $(DESTDIR)/usr/local/bin |
| 64 | -USE_SYSTEM_SQLITE = | |
| 64 | +USE_SYSTEM_SQLITE = | |
| 65 | 65 | USE_LINENOISE = 1 |
| 66 | 66 | # FOSSIL_ENABLE_TCL = @FOSSIL_ENABLE_TCL@ |
| 67 | 67 | FOSSIL_ENABLE_TCL = 0 |
| 68 | 68 | FOSSIL_ENABLE_MINIZ = 0 |
| 69 | 69 | |
| 70 | 70 | include $(SRCDIR)/main.mk |
| 71 | 71 | |
| 72 | 72 | distclean: clean |
| 73 | 73 | rm -f autoconfig.h config.log Makefile |
| 74 | 74 |
| --- Makefile.osx-jaguar | |
| +++ Makefile.osx-jaguar | |
| @@ -38,11 +38,11 @@ | |
| 38 | BCCFLAGS = $(CFLAGS) |
| 39 | |
| 40 | #### The suffix to add to final executable file. When cross-compiling |
| 41 | # to windows, make this ".exe". Otherwise leave it blank. |
| 42 | # |
| 43 | E = |
| 44 | |
| 45 | TCC = cc |
| 46 | TCCFLAGS = $(CFLAGS) |
| 47 | |
| 48 | #### Tcl shell for use in running the fossil testsuite. If you do not |
| @@ -59,15 +59,15 @@ | |
| 59 | TCC += -DWITHOUT_ICONV |
| 60 | TCC += -Dsocklen_t=int |
| 61 | TCC += -DSQLITE_MAX_MMAP_SIZE=0 |
| 62 | TCC += -DFOSSIL_ENABLE_LEGACY_MV_RM=1 |
| 63 | INSTALLDIR = $(DESTDIR)/usr/local/bin |
| 64 | USE_SYSTEM_SQLITE = |
| 65 | USE_LINENOISE = 1 |
| 66 | # FOSSIL_ENABLE_TCL = @FOSSIL_ENABLE_TCL@ |
| 67 | FOSSIL_ENABLE_TCL = 0 |
| 68 | FOSSIL_ENABLE_MINIZ = 0 |
| 69 | |
| 70 | include $(SRCDIR)/main.mk |
| 71 | |
| 72 | distclean: clean |
| 73 | rm -f autoconfig.h config.log Makefile |
| 74 |
| --- Makefile.osx-jaguar | |
| +++ Makefile.osx-jaguar | |
| @@ -38,11 +38,11 @@ | |
| 38 | BCCFLAGS = $(CFLAGS) |
| 39 | |
| 40 | #### The suffix to add to final executable file. When cross-compiling |
| 41 | # to windows, make this ".exe". Otherwise leave it blank. |
| 42 | # |
| 43 | E = |
| 44 | |
| 45 | TCC = cc |
| 46 | TCCFLAGS = $(CFLAGS) |
| 47 | |
| 48 | #### Tcl shell for use in running the fossil testsuite. If you do not |
| @@ -59,15 +59,15 @@ | |
| 59 | TCC += -DWITHOUT_ICONV |
| 60 | TCC += -Dsocklen_t=int |
| 61 | TCC += -DSQLITE_MAX_MMAP_SIZE=0 |
| 62 | TCC += -DFOSSIL_ENABLE_LEGACY_MV_RM=1 |
| 63 | INSTALLDIR = $(DESTDIR)/usr/local/bin |
| 64 | USE_SYSTEM_SQLITE = |
| 65 | USE_LINENOISE = 1 |
| 66 | # FOSSIL_ENABLE_TCL = @FOSSIL_ENABLE_TCL@ |
| 67 | FOSSIL_ENABLE_TCL = 0 |
| 68 | FOSSIL_ENABLE_MINIZ = 0 |
| 69 | |
| 70 | include $(SRCDIR)/main.mk |
| 71 | |
| 72 | distclean: clean |
| 73 | rm -f autoconfig.h config.log Makefile |
| 74 |
| --- win/Makefile.mingw.mistachkin | ||
| +++ win/Makefile.mingw.mistachkin | ||
| @@ -463,10 +463,11 @@ | ||
| 463 | 463 | $(SRCDIR)/content.c \ |
| 464 | 464 | $(SRCDIR)/cookies.c \ |
| 465 | 465 | $(SRCDIR)/db.c \ |
| 466 | 466 | $(SRCDIR)/delta.c \ |
| 467 | 467 | $(SRCDIR)/deltacmd.c \ |
| 468 | + $(SRCDIR)/deltafunc.c \ | |
| 468 | 469 | $(SRCDIR)/descendants.c \ |
| 469 | 470 | $(SRCDIR)/diff.c \ |
| 470 | 471 | $(SRCDIR)/diffcmd.c \ |
| 471 | 472 | $(SRCDIR)/dispatch.c \ |
| 472 | 473 | $(SRCDIR)/doc.c \ |
| @@ -674,10 +675,11 @@ | ||
| 674 | 675 | $(OBJDIR)/content_.c \ |
| 675 | 676 | $(OBJDIR)/cookies_.c \ |
| 676 | 677 | $(OBJDIR)/db_.c \ |
| 677 | 678 | $(OBJDIR)/delta_.c \ |
| 678 | 679 | $(OBJDIR)/deltacmd_.c \ |
| 680 | + $(OBJDIR)/deltafunc_.c \ | |
| 679 | 681 | $(OBJDIR)/descendants_.c \ |
| 680 | 682 | $(OBJDIR)/diff_.c \ |
| 681 | 683 | $(OBJDIR)/diffcmd_.c \ |
| 682 | 684 | $(OBJDIR)/dispatch_.c \ |
| 683 | 685 | $(OBJDIR)/doc_.c \ |
| @@ -812,10 +814,11 @@ | ||
| 812 | 814 | $(OBJDIR)/content.o \ |
| 813 | 815 | $(OBJDIR)/cookies.o \ |
| 814 | 816 | $(OBJDIR)/db.o \ |
| 815 | 817 | $(OBJDIR)/delta.o \ |
| 816 | 818 | $(OBJDIR)/deltacmd.o \ |
| 819 | + $(OBJDIR)/deltafunc.o \ | |
| 817 | 820 | $(OBJDIR)/descendants.o \ |
| 818 | 821 | $(OBJDIR)/diff.o \ |
| 819 | 822 | $(OBJDIR)/diffcmd.o \ |
| 820 | 823 | $(OBJDIR)/dispatch.o \ |
| 821 | 824 | $(OBJDIR)/doc.o \ |
| @@ -1169,10 +1172,11 @@ | ||
| 1169 | 1172 | $(OBJDIR)/content_.c:$(OBJDIR)/content.h \ |
| 1170 | 1173 | $(OBJDIR)/cookies_.c:$(OBJDIR)/cookies.h \ |
| 1171 | 1174 | $(OBJDIR)/db_.c:$(OBJDIR)/db.h \ |
| 1172 | 1175 | $(OBJDIR)/delta_.c:$(OBJDIR)/delta.h \ |
| 1173 | 1176 | $(OBJDIR)/deltacmd_.c:$(OBJDIR)/deltacmd.h \ |
| 1177 | + $(OBJDIR)/deltafunc_.c:$(OBJDIR)/deltafunc.h \ | |
| 1174 | 1178 | $(OBJDIR)/descendants_.c:$(OBJDIR)/descendants.h \ |
| 1175 | 1179 | $(OBJDIR)/diff_.c:$(OBJDIR)/diff.h \ |
| 1176 | 1180 | $(OBJDIR)/diffcmd_.c:$(OBJDIR)/diffcmd.h \ |
| 1177 | 1181 | $(OBJDIR)/dispatch_.c:$(OBJDIR)/dispatch.h \ |
| 1178 | 1182 | $(OBJDIR)/doc_.c:$(OBJDIR)/doc.h \ |
| @@ -1502,10 +1506,18 @@ | ||
| 1502 | 1506 | |
| 1503 | 1507 | $(OBJDIR)/deltacmd.o: $(OBJDIR)/deltacmd_.c $(OBJDIR)/deltacmd.h $(SRCDIR)/config.h |
| 1504 | 1508 | $(XTCC) -o $(OBJDIR)/deltacmd.o -c $(OBJDIR)/deltacmd_.c |
| 1505 | 1509 | |
| 1506 | 1510 | $(OBJDIR)/deltacmd.h: $(OBJDIR)/headers |
| 1511 | + | |
| 1512 | +$(OBJDIR)/deltafunc_.c: $(SRCDIR)/deltafunc.c $(TRANSLATE) | |
| 1513 | + $(TRANSLATE) $(SRCDIR)/deltafunc.c >$@ | |
| 1514 | + | |
| 1515 | +$(OBJDIR)/deltafunc.o: $(OBJDIR)/deltafunc_.c $(OBJDIR)/deltafunc.h $(SRCDIR)/config.h | |
| 1516 | + $(XTCC) -o $(OBJDIR)/deltafunc.o -c $(OBJDIR)/deltafunc_.c | |
| 1517 | + | |
| 1518 | +$(OBJDIR)/deltafunc.h: $(OBJDIR)/headers | |
| 1507 | 1519 | |
| 1508 | 1520 | $(OBJDIR)/descendants_.c: $(SRCDIR)/descendants.c $(TRANSLATE) |
| 1509 | 1521 | $(TRANSLATE) $(SRCDIR)/descendants.c >$@ |
| 1510 | 1522 | |
| 1511 | 1523 | $(OBJDIR)/descendants.o: $(OBJDIR)/descendants_.c $(OBJDIR)/descendants.h $(SRCDIR)/config.h |
| 1512 | 1524 |
| --- win/Makefile.mingw.mistachkin | |
| +++ win/Makefile.mingw.mistachkin | |
| @@ -463,10 +463,11 @@ | |
| 463 | $(SRCDIR)/content.c \ |
| 464 | $(SRCDIR)/cookies.c \ |
| 465 | $(SRCDIR)/db.c \ |
| 466 | $(SRCDIR)/delta.c \ |
| 467 | $(SRCDIR)/deltacmd.c \ |
| 468 | $(SRCDIR)/descendants.c \ |
| 469 | $(SRCDIR)/diff.c \ |
| 470 | $(SRCDIR)/diffcmd.c \ |
| 471 | $(SRCDIR)/dispatch.c \ |
| 472 | $(SRCDIR)/doc.c \ |
| @@ -674,10 +675,11 @@ | |
| 674 | $(OBJDIR)/content_.c \ |
| 675 | $(OBJDIR)/cookies_.c \ |
| 676 | $(OBJDIR)/db_.c \ |
| 677 | $(OBJDIR)/delta_.c \ |
| 678 | $(OBJDIR)/deltacmd_.c \ |
| 679 | $(OBJDIR)/descendants_.c \ |
| 680 | $(OBJDIR)/diff_.c \ |
| 681 | $(OBJDIR)/diffcmd_.c \ |
| 682 | $(OBJDIR)/dispatch_.c \ |
| 683 | $(OBJDIR)/doc_.c \ |
| @@ -812,10 +814,11 @@ | |
| 812 | $(OBJDIR)/content.o \ |
| 813 | $(OBJDIR)/cookies.o \ |
| 814 | $(OBJDIR)/db.o \ |
| 815 | $(OBJDIR)/delta.o \ |
| 816 | $(OBJDIR)/deltacmd.o \ |
| 817 | $(OBJDIR)/descendants.o \ |
| 818 | $(OBJDIR)/diff.o \ |
| 819 | $(OBJDIR)/diffcmd.o \ |
| 820 | $(OBJDIR)/dispatch.o \ |
| 821 | $(OBJDIR)/doc.o \ |
| @@ -1169,10 +1172,11 @@ | |
| 1169 | $(OBJDIR)/content_.c:$(OBJDIR)/content.h \ |
| 1170 | $(OBJDIR)/cookies_.c:$(OBJDIR)/cookies.h \ |
| 1171 | $(OBJDIR)/db_.c:$(OBJDIR)/db.h \ |
| 1172 | $(OBJDIR)/delta_.c:$(OBJDIR)/delta.h \ |
| 1173 | $(OBJDIR)/deltacmd_.c:$(OBJDIR)/deltacmd.h \ |
| 1174 | $(OBJDIR)/descendants_.c:$(OBJDIR)/descendants.h \ |
| 1175 | $(OBJDIR)/diff_.c:$(OBJDIR)/diff.h \ |
| 1176 | $(OBJDIR)/diffcmd_.c:$(OBJDIR)/diffcmd.h \ |
| 1177 | $(OBJDIR)/dispatch_.c:$(OBJDIR)/dispatch.h \ |
| 1178 | $(OBJDIR)/doc_.c:$(OBJDIR)/doc.h \ |
| @@ -1502,10 +1506,18 @@ | |
| 1502 | |
| 1503 | $(OBJDIR)/deltacmd.o: $(OBJDIR)/deltacmd_.c $(OBJDIR)/deltacmd.h $(SRCDIR)/config.h |
| 1504 | $(XTCC) -o $(OBJDIR)/deltacmd.o -c $(OBJDIR)/deltacmd_.c |
| 1505 | |
| 1506 | $(OBJDIR)/deltacmd.h: $(OBJDIR)/headers |
| 1507 | |
| 1508 | $(OBJDIR)/descendants_.c: $(SRCDIR)/descendants.c $(TRANSLATE) |
| 1509 | $(TRANSLATE) $(SRCDIR)/descendants.c >$@ |
| 1510 | |
| 1511 | $(OBJDIR)/descendants.o: $(OBJDIR)/descendants_.c $(OBJDIR)/descendants.h $(SRCDIR)/config.h |
| 1512 |
| --- win/Makefile.mingw.mistachkin | |
| +++ win/Makefile.mingw.mistachkin | |
| @@ -463,10 +463,11 @@ | |
| 463 | $(SRCDIR)/content.c \ |
| 464 | $(SRCDIR)/cookies.c \ |
| 465 | $(SRCDIR)/db.c \ |
| 466 | $(SRCDIR)/delta.c \ |
| 467 | $(SRCDIR)/deltacmd.c \ |
| 468 | $(SRCDIR)/deltafunc.c \ |
| 469 | $(SRCDIR)/descendants.c \ |
| 470 | $(SRCDIR)/diff.c \ |
| 471 | $(SRCDIR)/diffcmd.c \ |
| 472 | $(SRCDIR)/dispatch.c \ |
| 473 | $(SRCDIR)/doc.c \ |
| @@ -674,10 +675,11 @@ | |
| 675 | $(OBJDIR)/content_.c \ |
| 676 | $(OBJDIR)/cookies_.c \ |
| 677 | $(OBJDIR)/db_.c \ |
| 678 | $(OBJDIR)/delta_.c \ |
| 679 | $(OBJDIR)/deltacmd_.c \ |
| 680 | $(OBJDIR)/deltafunc_.c \ |
| 681 | $(OBJDIR)/descendants_.c \ |
| 682 | $(OBJDIR)/diff_.c \ |
| 683 | $(OBJDIR)/diffcmd_.c \ |
| 684 | $(OBJDIR)/dispatch_.c \ |
| 685 | $(OBJDIR)/doc_.c \ |
| @@ -812,10 +814,11 @@ | |
| 814 | $(OBJDIR)/content.o \ |
| 815 | $(OBJDIR)/cookies.o \ |
| 816 | $(OBJDIR)/db.o \ |
| 817 | $(OBJDIR)/delta.o \ |
| 818 | $(OBJDIR)/deltacmd.o \ |
| 819 | $(OBJDIR)/deltafunc.o \ |
| 820 | $(OBJDIR)/descendants.o \ |
| 821 | $(OBJDIR)/diff.o \ |
| 822 | $(OBJDIR)/diffcmd.o \ |
| 823 | $(OBJDIR)/dispatch.o \ |
| 824 | $(OBJDIR)/doc.o \ |
| @@ -1169,10 +1172,11 @@ | |
| 1172 | $(OBJDIR)/content_.c:$(OBJDIR)/content.h \ |
| 1173 | $(OBJDIR)/cookies_.c:$(OBJDIR)/cookies.h \ |
| 1174 | $(OBJDIR)/db_.c:$(OBJDIR)/db.h \ |
| 1175 | $(OBJDIR)/delta_.c:$(OBJDIR)/delta.h \ |
| 1176 | $(OBJDIR)/deltacmd_.c:$(OBJDIR)/deltacmd.h \ |
| 1177 | $(OBJDIR)/deltafunc_.c:$(OBJDIR)/deltafunc.h \ |
| 1178 | $(OBJDIR)/descendants_.c:$(OBJDIR)/descendants.h \ |
| 1179 | $(OBJDIR)/diff_.c:$(OBJDIR)/diff.h \ |
| 1180 | $(OBJDIR)/diffcmd_.c:$(OBJDIR)/diffcmd.h \ |
| 1181 | $(OBJDIR)/dispatch_.c:$(OBJDIR)/dispatch.h \ |
| 1182 | $(OBJDIR)/doc_.c:$(OBJDIR)/doc.h \ |
| @@ -1502,10 +1506,18 @@ | |
| 1506 | |
| 1507 | $(OBJDIR)/deltacmd.o: $(OBJDIR)/deltacmd_.c $(OBJDIR)/deltacmd.h $(SRCDIR)/config.h |
| 1508 | $(XTCC) -o $(OBJDIR)/deltacmd.o -c $(OBJDIR)/deltacmd_.c |
| 1509 | |
| 1510 | $(OBJDIR)/deltacmd.h: $(OBJDIR)/headers |
| 1511 | |
| 1512 | $(OBJDIR)/deltafunc_.c: $(SRCDIR)/deltafunc.c $(TRANSLATE) |
| 1513 | $(TRANSLATE) $(SRCDIR)/deltafunc.c >$@ |
| 1514 | |
| 1515 | $(OBJDIR)/deltafunc.o: $(OBJDIR)/deltafunc_.c $(OBJDIR)/deltafunc.h $(SRCDIR)/config.h |
| 1516 | $(XTCC) -o $(OBJDIR)/deltafunc.o -c $(OBJDIR)/deltafunc_.c |
| 1517 | |
| 1518 | $(OBJDIR)/deltafunc.h: $(OBJDIR)/headers |
| 1519 | |
| 1520 | $(OBJDIR)/descendants_.c: $(SRCDIR)/descendants.c $(TRANSLATE) |
| 1521 | $(TRANSLATE) $(SRCDIR)/descendants.c >$@ |
| 1522 | |
| 1523 | $(OBJDIR)/descendants.o: $(OBJDIR)/descendants_.c $(OBJDIR)/descendants.h $(SRCDIR)/config.h |
| 1524 |
+2
-2
| --- www/admin-v-setup.md | ||
| +++ www/admin-v-setup.md | ||
| @@ -2,11 +2,11 @@ | ||
| 2 | 2 | |
| 3 | 3 | Several of the Fossil user capabilities form a clear power hierarchy. |
| 4 | 4 | Mathematically speaking: |
| 5 | 5 | |
| 6 | 6 | > *Setup > Admin > Moderator > User > Subscriber > Anonymous > Nobody* |
| 7 | - | |
| 7 | + | |
| 8 | 8 | This document explains the distinction between the first two. For the |
| 9 | 9 | others, see: |
| 10 | 10 | |
| 11 | 11 | * [How Moderation Works](./forum.wiki#moderation) |
| 12 | 12 | |
| @@ -285,11 +285,11 @@ | ||
| 285 | 285 | |
| 286 | 286 | * <p><b>Risky</b>: The <tt>https-login</tt> setting falls under |
| 287 | 287 | the "Security" section above, but it should probably never be |
| 288 | 288 | adjusted by Admin-only users. Sites that want it on will never |
| 289 | 289 | want it to be disabled without a very good reason.</p> |
| 290 | - | |
| 290 | + | |
| 291 | 291 | <p>There is also an inverse risk: if the site has a front-end |
| 292 | 292 | HTTPS proxy that uses HTTP to communicate over localhost to |
| 293 | 293 | Fossil, enabling this setting will create an infinite redirect |
| 294 | 294 | loop! (Ask me how I know.)</p> |
| 295 | 295 | |
| 296 | 296 |
| --- www/admin-v-setup.md | |
| +++ www/admin-v-setup.md | |
| @@ -2,11 +2,11 @@ | |
| 2 | |
| 3 | Several of the Fossil user capabilities form a clear power hierarchy. |
| 4 | Mathematically speaking: |
| 5 | |
| 6 | > *Setup > Admin > Moderator > User > Subscriber > Anonymous > Nobody* |
| 7 | |
| 8 | This document explains the distinction between the first two. For the |
| 9 | others, see: |
| 10 | |
| 11 | * [How Moderation Works](./forum.wiki#moderation) |
| 12 | |
| @@ -285,11 +285,11 @@ | |
| 285 | |
| 286 | * <p><b>Risky</b>: The <tt>https-login</tt> setting falls under |
| 287 | the "Security" section above, but it should probably never be |
| 288 | adjusted by Admin-only users. Sites that want it on will never |
| 289 | want it to be disabled without a very good reason.</p> |
| 290 | |
| 291 | <p>There is also an inverse risk: if the site has a front-end |
| 292 | HTTPS proxy that uses HTTP to communicate over localhost to |
| 293 | Fossil, enabling this setting will create an infinite redirect |
| 294 | loop! (Ask me how I know.)</p> |
| 295 | |
| 296 |
| --- www/admin-v-setup.md | |
| +++ www/admin-v-setup.md | |
| @@ -2,11 +2,11 @@ | |
| 2 | |
| 3 | Several of the Fossil user capabilities form a clear power hierarchy. |
| 4 | Mathematically speaking: |
| 5 | |
| 6 | > *Setup > Admin > Moderator > User > Subscriber > Anonymous > Nobody* |
| 7 | |
| 8 | This document explains the distinction between the first two. For the |
| 9 | others, see: |
| 10 | |
| 11 | * [How Moderation Works](./forum.wiki#moderation) |
| 12 | |
| @@ -285,11 +285,11 @@ | |
| 285 | |
| 286 | * <p><b>Risky</b>: The <tt>https-login</tt> setting falls under |
| 287 | the "Security" section above, but it should probably never be |
| 288 | adjusted by Admin-only users. Sites that want it on will never |
| 289 | want it to be disabled without a very good reason.</p> |
| 290 | |
| 291 | <p>There is also an inverse risk: if the site has a front-end |
| 292 | HTTPS proxy that uses HTTP to communicate over localhost to |
| 293 | Fossil, enabling this setting will create an infinite redirect |
| 294 | loop! (Ask me how I know.)</p> |
| 295 | |
| 296 |
+8
-8
| --- www/backoffice.md | ||
| +++ www/backoffice.md | ||
| @@ -2,17 +2,17 @@ | ||
| 2 | 2 | ========== |
| 3 | 3 | |
| 4 | 4 | This is technical documentation about the internal workings of Fossil. |
| 5 | 5 | Ordinary Fossil users do not need to know about anything covered by this |
| 6 | 6 | document. The information here is intended for people who want to enhance |
| 7 | -or extend the Fossil code, or who just want a deeper understanding of | |
| 7 | +or extend the Fossil code, or who just want a deeper understanding of | |
| 8 | 8 | the internal workings of Fossil. |
| 9 | 9 | |
| 10 | 10 | What Is The Backoffice |
| 11 | 11 | ---------------------- |
| 12 | 12 | |
| 13 | -The backoffice is a mechanism used by a | |
| 13 | +The backoffice is a mechanism used by a | |
| 14 | 14 | [Fossil server](/doc/trunk/www/server.wiki) to do low-priority |
| 15 | 15 | background work that is not directly related to the user interface. Here |
| 16 | 16 | are some examples of the kinds of work that backoffice performs: |
| 17 | 17 | |
| 18 | 18 | 1. Sending email alerts and notifications |
| @@ -49,20 +49,20 @@ | ||
| 49 | 49 | The backoffice is not a daemon. Each backoffice process runs for a short |
| 50 | 50 | while and then exits. This helps keep Fossil easy to manage, since there |
| 51 | 51 | are no daemons to start and stop. To upgrade Fossil to a new version, |
| 52 | 52 | you simply replace the older "fossil" executable with the newer one, and |
| 53 | 53 | the backoffice processes will (within a minute or so) start using the new |
| 54 | -one. (Upgrading the executable on Windows is more complicated, since on | |
| 55 | -Windows it is not possible to replace an executable file that is in active | |
| 54 | +one. (Upgrading the executable on Windows is more complicated, since on | |
| 55 | +Windows it is not possible to replace an executable file that is in active | |
| 56 | 56 | use. But Windows users probably already know this.) |
| 57 | 57 | |
| 58 | 58 | The backoffice is serialized and rate limited. No more than a single |
| 59 | 59 | backoffice process will be running at once, and backoffice runs will not |
| 60 | 60 | occur more frequently than once every 60 seconds. |
| 61 | 61 | |
| 62 | 62 | If a Fossil server is idle, then no backoffice processes will be running. |
| 63 | -That means there are no extra processes sitting around taking up memory | |
| 63 | +That means there are no extra processes sitting around taking up memory | |
| 64 | 64 | and process table slots for seldom accessed repositories. |
| 65 | 65 | The backoffice is an on-demand system. |
| 66 | 66 | A busy repository will usually have a backoffice |
| 67 | 67 | running at all times. But an infrequently accessed repository will only have |
| 68 | 68 | backoffice processes running for a minute or two following the most recent |
| @@ -118,13 +118,13 @@ | ||
| 118 | 118 | If a system has been idle for a long time, then there will be no |
| 119 | 119 | backoffice processes. (Either the process id entries in the lease |
| 120 | 120 | will be zero, or there will exist no process associated with the |
| 121 | 121 | process id.) When a new web request comes in, the system |
| 122 | 122 | sees that no backoffice process is active and so it kicks off a separate |
| 123 | -process to run backoffice. | |
| 123 | +process to run backoffice. | |
| 124 | 124 | |
| 125 | -The new backoffice process becomes the "current" process. It sets a | |
| 125 | +The new backoffice process becomes the "current" process. It sets a | |
| 126 | 126 | lease expiration time for itself to be 60 seconds in the future. |
| 127 | 127 | Then it does the backoffice processing and exits. Note that usually |
| 128 | 128 | the backoffice process will exit long before its lease expires. That |
| 129 | 129 | is ok. The lease is there to limit the rate at which backoffice processes |
| 130 | 130 | run. |
| @@ -180,10 +180,10 @@ | ||
| 180 | 180 | process actually starts to do the backoffice work. This log file can |
| 181 | 181 | be used to verify that backoffice really is running, if there is any |
| 182 | 182 | doubt. The "backoffice-disable" setting prevents automatic backoffice |
| 183 | 183 | processing, if true. Use this to completely disable backoffice processing |
| 184 | 184 | that occurs automatically after each HTTP request. The "backoffice-disable" |
| 185 | -setting does not affect the operation of the manual | |
| 185 | +setting does not affect the operation of the manual | |
| 186 | 186 | "fossil backoffice" command. |
| 187 | 187 | Most installations should leave "backoffice-nodelay" and "backoffice-disable" |
| 188 | 188 | set to their default values of off and |
| 189 | 189 | leave "backoffice-logfile" unset or set to an empty string. |
| 190 | 190 |
| --- www/backoffice.md | |
| +++ www/backoffice.md | |
| @@ -2,17 +2,17 @@ | |
| 2 | ========== |
| 3 | |
| 4 | This is technical documentation about the internal workings of Fossil. |
| 5 | Ordinary Fossil users do not need to know about anything covered by this |
| 6 | document. The information here is intended for people who want to enhance |
| 7 | or extend the Fossil code, or who just want a deeper understanding of |
| 8 | the internal workings of Fossil. |
| 9 | |
| 10 | What Is The Backoffice |
| 11 | ---------------------- |
| 12 | |
| 13 | The backoffice is a mechanism used by a |
| 14 | [Fossil server](/doc/trunk/www/server.wiki) to do low-priority |
| 15 | background work that is not directly related to the user interface. Here |
| 16 | are some examples of the kinds of work that backoffice performs: |
| 17 | |
| 18 | 1. Sending email alerts and notifications |
| @@ -49,20 +49,20 @@ | |
| 49 | The backoffice is not a daemon. Each backoffice process runs for a short |
| 50 | while and then exits. This helps keep Fossil easy to manage, since there |
| 51 | are no daemons to start and stop. To upgrade Fossil to a new version, |
| 52 | you simply replace the older "fossil" executable with the newer one, and |
| 53 | the backoffice processes will (within a minute or so) start using the new |
| 54 | one. (Upgrading the executable on Windows is more complicated, since on |
| 55 | Windows it is not possible to replace an executable file that is in active |
| 56 | use. But Windows users probably already know this.) |
| 57 | |
| 58 | The backoffice is serialized and rate limited. No more than a single |
| 59 | backoffice process will be running at once, and backoffice runs will not |
| 60 | occur more frequently than once every 60 seconds. |
| 61 | |
| 62 | If a Fossil server is idle, then no backoffice processes will be running. |
| 63 | That means there are no extra processes sitting around taking up memory |
| 64 | and process table slots for seldom accessed repositories. |
| 65 | The backoffice is an on-demand system. |
| 66 | A busy repository will usually have a backoffice |
| 67 | running at all times. But an infrequently accessed repository will only have |
| 68 | backoffice processes running for a minute or two following the most recent |
| @@ -118,13 +118,13 @@ | |
| 118 | If a system has been idle for a long time, then there will be no |
| 119 | backoffice processes. (Either the process id entries in the lease |
| 120 | will be zero, or there will exist no process associated with the |
| 121 | process id.) When a new web request comes in, the system |
| 122 | sees that no backoffice process is active and so it kicks off a separate |
| 123 | process to run backoffice. |
| 124 | |
| 125 | The new backoffice process becomes the "current" process. It sets a |
| 126 | lease expiration time for itself to be 60 seconds in the future. |
| 127 | Then it does the backoffice processing and exits. Note that usually |
| 128 | the backoffice process will exit long before its lease expires. That |
| 129 | is ok. The lease is there to limit the rate at which backoffice processes |
| 130 | run. |
| @@ -180,10 +180,10 @@ | |
| 180 | process actually starts to do the backoffice work. This log file can |
| 181 | be used to verify that backoffice really is running, if there is any |
| 182 | doubt. The "backoffice-disable" setting prevents automatic backoffice |
| 183 | processing, if true. Use this to completely disable backoffice processing |
| 184 | that occurs automatically after each HTTP request. The "backoffice-disable" |
| 185 | setting does not affect the operation of the manual |
| 186 | "fossil backoffice" command. |
| 187 | Most installations should leave "backoffice-nodelay" and "backoffice-disable" |
| 188 | set to their default values of off and |
| 189 | leave "backoffice-logfile" unset or set to an empty string. |
| 190 |
| --- www/backoffice.md | |
| +++ www/backoffice.md | |
| @@ -2,17 +2,17 @@ | |
| 2 | ========== |
| 3 | |
| 4 | This is technical documentation about the internal workings of Fossil. |
| 5 | Ordinary Fossil users do not need to know about anything covered by this |
| 6 | document. The information here is intended for people who want to enhance |
| 7 | or extend the Fossil code, or who just want a deeper understanding of |
| 8 | the internal workings of Fossil. |
| 9 | |
| 10 | What Is The Backoffice |
| 11 | ---------------------- |
| 12 | |
| 13 | The backoffice is a mechanism used by a |
| 14 | [Fossil server](/doc/trunk/www/server.wiki) to do low-priority |
| 15 | background work that is not directly related to the user interface. Here |
| 16 | are some examples of the kinds of work that backoffice performs: |
| 17 | |
| 18 | 1. Sending email alerts and notifications |
| @@ -49,20 +49,20 @@ | |
| 49 | The backoffice is not a daemon. Each backoffice process runs for a short |
| 50 | while and then exits. This helps keep Fossil easy to manage, since there |
| 51 | are no daemons to start and stop. To upgrade Fossil to a new version, |
| 52 | you simply replace the older "fossil" executable with the newer one, and |
| 53 | the backoffice processes will (within a minute or so) start using the new |
| 54 | one. (Upgrading the executable on Windows is more complicated, since on |
| 55 | Windows it is not possible to replace an executable file that is in active |
| 56 | use. But Windows users probably already know this.) |
| 57 | |
| 58 | The backoffice is serialized and rate limited. No more than a single |
| 59 | backoffice process will be running at once, and backoffice runs will not |
| 60 | occur more frequently than once every 60 seconds. |
| 61 | |
| 62 | If a Fossil server is idle, then no backoffice processes will be running. |
| 63 | That means there are no extra processes sitting around taking up memory |
| 64 | and process table slots for seldom accessed repositories. |
| 65 | The backoffice is an on-demand system. |
| 66 | A busy repository will usually have a backoffice |
| 67 | running at all times. But an infrequently accessed repository will only have |
| 68 | backoffice processes running for a minute or two following the most recent |
| @@ -118,13 +118,13 @@ | |
| 118 | If a system has been idle for a long time, then there will be no |
| 119 | backoffice processes. (Either the process id entries in the lease |
| 120 | will be zero, or there will exist no process associated with the |
| 121 | process id.) When a new web request comes in, the system |
| 122 | sees that no backoffice process is active and so it kicks off a separate |
| 123 | process to run backoffice. |
| 124 | |
| 125 | The new backoffice process becomes the "current" process. It sets a |
| 126 | lease expiration time for itself to be 60 seconds in the future. |
| 127 | Then it does the backoffice processing and exits. Note that usually |
| 128 | the backoffice process will exit long before its lease expires. That |
| 129 | is ok. The lease is there to limit the rate at which backoffice processes |
| 130 | run. |
| @@ -180,10 +180,10 @@ | |
| 180 | process actually starts to do the backoffice work. This log file can |
| 181 | be used to verify that backoffice really is running, if there is any |
| 182 | doubt. The "backoffice-disable" setting prevents automatic backoffice |
| 183 | processing, if true. Use this to completely disable backoffice processing |
| 184 | that occurs automatically after each HTTP request. The "backoffice-disable" |
| 185 | setting does not affect the operation of the manual |
| 186 | "fossil backoffice" command. |
| 187 | Most installations should leave "backoffice-nodelay" and "backoffice-disable" |
| 188 | set to their default values of off and |
| 189 | leave "backoffice-logfile" unset or set to an empty string. |
| 190 |
+1
-1
| --- www/blockchain.md | ||
| +++ www/blockchain.md | ||
| @@ -20,11 +20,11 @@ | ||
| 20 | 20 | and since Fossil has nothing to do with cryptocurrency, the claim that |
| 21 | 21 | Fossil is build around blockchain is met with skepticism. The key thing |
| 22 | 22 | to note here is that cryptocurrency implementations like BitCoin are |
| 23 | 23 | built around blockchain, but they are not synonymous with blockchain. |
| 24 | 24 | Blockchain is a much broader concept. Blockchain is a mechanism for |
| 25 | -constructed a distributed ledger of transactions. | |
| 25 | +constructed a distributed ledger of transactions. | |
| 26 | 26 | Yes, you can use a distributed |
| 27 | 27 | ledger to implement a cryptocurrency, but you can also use a distributed |
| 28 | 28 | ledger to implement a version control system, and probably many other kinds |
| 29 | 29 | of applications as well. Blockchain is a much broader idea than |
| 30 | 30 | cryptocurrency. |
| 31 | 31 |
| --- www/blockchain.md | |
| +++ www/blockchain.md | |
| @@ -20,11 +20,11 @@ | |
| 20 | and since Fossil has nothing to do with cryptocurrency, the claim that |
| 21 | Fossil is build around blockchain is met with skepticism. The key thing |
| 22 | to note here is that cryptocurrency implementations like BitCoin are |
| 23 | built around blockchain, but they are not synonymous with blockchain. |
| 24 | Blockchain is a much broader concept. Blockchain is a mechanism for |
| 25 | constructed a distributed ledger of transactions. |
| 26 | Yes, you can use a distributed |
| 27 | ledger to implement a cryptocurrency, but you can also use a distributed |
| 28 | ledger to implement a version control system, and probably many other kinds |
| 29 | of applications as well. Blockchain is a much broader idea than |
| 30 | cryptocurrency. |
| 31 |
| --- www/blockchain.md | |
| +++ www/blockchain.md | |
| @@ -20,11 +20,11 @@ | |
| 20 | and since Fossil has nothing to do with cryptocurrency, the claim that |
| 21 | Fossil is build around blockchain is met with skepticism. The key thing |
| 22 | to note here is that cryptocurrency implementations like BitCoin are |
| 23 | built around blockchain, but they are not synonymous with blockchain. |
| 24 | Blockchain is a much broader concept. Blockchain is a mechanism for |
| 25 | constructed a distributed ledger of transactions. |
| 26 | Yes, you can use a distributed |
| 27 | ledger to implement a cryptocurrency, but you can also use a distributed |
| 28 | ledger to implement a version control system, and probably many other kinds |
| 29 | of applications as well. Blockchain is a much broader idea than |
| 30 | cryptocurrency. |
| 31 |
+7
-7
| --- www/changes.wiki | ||
| +++ www/changes.wiki | ||
| @@ -1,16 +1,16 @@ | ||
| 1 | 1 | <title>Change Log</title> |
| 2 | 2 | |
| 3 | 3 | <a name='v2_9'></a> |
| 4 | 4 | <h2>Changes for Version 2.9 (pending)</h2> |
| 5 | 5 | |
| 6 | - * Improved handling of relative hyperlinks on the | |
| 6 | + * Improved handling of relative hyperlinks on the | |
| 7 | 7 | [/help?cmd=/artifact|/artifact] pages for wiki. For example, |
| 8 | 8 | hyperlinks and the lizard <img> now work correctly |
| 9 | - for both [/artifact/2ff24ab0887cf522] and | |
| 9 | + for both [/artifact/2ff24ab0887cf522] and | |
| 10 | 10 | [/doc/0d7ac90d575004c2415/www/index.wiki]. |
| 11 | - * For the "[/help?cmd=update|fossil update]" and | |
| 11 | + * For the "[/help?cmd=update|fossil update]" and | |
| 12 | 12 | "[/help?cmd=checkout|fossil checkout]" commands, if a |
| 13 | 13 | managed file is removed because it is no longer part of the target |
| 14 | 14 | check-in and the directory containing the file is empty after the |
| 15 | 15 | file is removed and the directory is not the current working |
| 16 | 16 | directory and is not on the [/help?cmd=empty-dirs|empty-dirs] |
| @@ -25,18 +25,18 @@ | ||
| 25 | 25 | <a name='v2_8'></a> |
| 26 | 26 | <h2>Changes for Version 2.8 (2019-02-20)</h2> |
| 27 | 27 | |
| 28 | 28 | * Show cherry-pick merges as dotted lines on the timeline graph. |
| 29 | 29 | → The "fossil rebuild" command must be run to create and |
| 30 | - populate the new "cherrypick" table in the repository in order | |
| 30 | + populate the new "cherrypick" table in the repository in order | |
| 31 | 31 | for this feature to operate. |
| 32 | 32 | * Add the ability to associate branches, check-ins, and tags with |
| 33 | 33 | specially-named Wiki pages. This gives the ability to better |
| 34 | 34 | document branches and tags, and provide more documentation on |
| 35 | 35 | check-ins beyond the check-in comment. The associated Wiki is |
| 36 | 36 | automatically displayed on /info pages for check-ins, and on |
| 37 | - /timeline?r=BRANCH and /timeline?t=TAG pages for branches and | |
| 37 | + /timeline?r=BRANCH and /timeline?t=TAG pages for branches and | |
| 38 | 38 | tags. This feature is on by default, but can be disabled in on |
| 39 | 39 | the Admin/Wiki page. |
| 40 | 40 | * Enhance the repository list page (shown for example by |
| 41 | 41 | "fossil all ui") so that it shows the name and last check-in |
| 42 | 42 | time for each project. The implementation of the repository |
| @@ -68,11 +68,11 @@ | ||
| 68 | 68 | * Enhancements to the "amend", "tag", and "reparent" commands, including |
| 69 | 69 | adding options --override-date, --override-user, and --dry-run. |
| 70 | 70 | * Add the global --comment-format command-line option and the |
| 71 | 71 | comment-format setting to control the display of the command-line |
| 72 | 72 | timeline. |
| 73 | - * Change the "fossil reparent" command so that it only works from | |
| 73 | + * Change the "fossil reparent" command so that it only works from | |
| 74 | 74 | within an active checkout. |
| 75 | 75 | * On the /setup_ucap_list, show administrators how many users have |
| 76 | 76 | each capability. The counts are a hyperlink to the /setup_ulist |
| 77 | 77 | page showing the subset of users that have that capability. |
| 78 | 78 | * Provide the ability to redirect all HTTP pages to HTTPS. Formerly |
| @@ -103,11 +103,11 @@ | ||
| 103 | 103 | User capabilities are now letters in [a-zA-Z0-9]. |
| 104 | 104 | * The built-in skins are now responsive, providing better layout on |
| 105 | 105 | small screens, including mobile devices. |
| 106 | 106 | * The default skin now includes a hamburger menu that is generated |
| 107 | 107 | by the [/sitemap] page. |
| 108 | - * All of the built-in skins now use a | |
| 108 | + * All of the built-in skins now use a | |
| 109 | 109 | [https://en.wikipedia.org/wiki/Content_Security_Policy|Content Security Policy (CSP)] |
| 110 | 110 | to help prevent cross-site injection and forgery attacks. There are no known |
| 111 | 111 | vulnerabilities in Fossil. The added CSP does not fix anything; it merely adds |
| 112 | 112 | another layer of defense. |
| 113 | 113 | * The [/sitemap] and other list pages show as multiple columns if |
| 114 | 114 |
| --- www/changes.wiki | |
| +++ www/changes.wiki | |
| @@ -1,16 +1,16 @@ | |
| 1 | <title>Change Log</title> |
| 2 | |
| 3 | <a name='v2_9'></a> |
| 4 | <h2>Changes for Version 2.9 (pending)</h2> |
| 5 | |
| 6 | * Improved handling of relative hyperlinks on the |
| 7 | [/help?cmd=/artifact|/artifact] pages for wiki. For example, |
| 8 | hyperlinks and the lizard <img> now work correctly |
| 9 | for both [/artifact/2ff24ab0887cf522] and |
| 10 | [/doc/0d7ac90d575004c2415/www/index.wiki]. |
| 11 | * For the "[/help?cmd=update|fossil update]" and |
| 12 | "[/help?cmd=checkout|fossil checkout]" commands, if a |
| 13 | managed file is removed because it is no longer part of the target |
| 14 | check-in and the directory containing the file is empty after the |
| 15 | file is removed and the directory is not the current working |
| 16 | directory and is not on the [/help?cmd=empty-dirs|empty-dirs] |
| @@ -25,18 +25,18 @@ | |
| 25 | <a name='v2_8'></a> |
| 26 | <h2>Changes for Version 2.8 (2019-02-20)</h2> |
| 27 | |
| 28 | * Show cherry-pick merges as dotted lines on the timeline graph. |
| 29 | → The "fossil rebuild" command must be run to create and |
| 30 | populate the new "cherrypick" table in the repository in order |
| 31 | for this feature to operate. |
| 32 | * Add the ability to associate branches, check-ins, and tags with |
| 33 | specially-named Wiki pages. This gives the ability to better |
| 34 | document branches and tags, and provide more documentation on |
| 35 | check-ins beyond the check-in comment. The associated Wiki is |
| 36 | automatically displayed on /info pages for check-ins, and on |
| 37 | /timeline?r=BRANCH and /timeline?t=TAG pages for branches and |
| 38 | tags. This feature is on by default, but can be disabled in on |
| 39 | the Admin/Wiki page. |
| 40 | * Enhance the repository list page (shown for example by |
| 41 | "fossil all ui") so that it shows the name and last check-in |
| 42 | time for each project. The implementation of the repository |
| @@ -68,11 +68,11 @@ | |
| 68 | * Enhancements to the "amend", "tag", and "reparent" commands, including |
| 69 | adding options --override-date, --override-user, and --dry-run. |
| 70 | * Add the global --comment-format command-line option and the |
| 71 | comment-format setting to control the display of the command-line |
| 72 | timeline. |
| 73 | * Change the "fossil reparent" command so that it only works from |
| 74 | within an active checkout. |
| 75 | * On the /setup_ucap_list, show administrators how many users have |
| 76 | each capability. The counts are a hyperlink to the /setup_ulist |
| 77 | page showing the subset of users that have that capability. |
| 78 | * Provide the ability to redirect all HTTP pages to HTTPS. Formerly |
| @@ -103,11 +103,11 @@ | |
| 103 | User capabilities are now letters in [a-zA-Z0-9]. |
| 104 | * The built-in skins are now responsive, providing better layout on |
| 105 | small screens, including mobile devices. |
| 106 | * The default skin now includes a hamburger menu that is generated |
| 107 | by the [/sitemap] page. |
| 108 | * All of the built-in skins now use a |
| 109 | [https://en.wikipedia.org/wiki/Content_Security_Policy|Content Security Policy (CSP)] |
| 110 | to help prevent cross-site injection and forgery attacks. There are no known |
| 111 | vulnerabilities in Fossil. The added CSP does not fix anything; it merely adds |
| 112 | another layer of defense. |
| 113 | * The [/sitemap] and other list pages show as multiple columns if |
| 114 |
| --- www/changes.wiki | |
| +++ www/changes.wiki | |
| @@ -1,16 +1,16 @@ | |
| 1 | <title>Change Log</title> |
| 2 | |
| 3 | <a name='v2_9'></a> |
| 4 | <h2>Changes for Version 2.9 (pending)</h2> |
| 5 | |
| 6 | * Improved handling of relative hyperlinks on the |
| 7 | [/help?cmd=/artifact|/artifact] pages for wiki. For example, |
| 8 | hyperlinks and the lizard <img> now work correctly |
| 9 | for both [/artifact/2ff24ab0887cf522] and |
| 10 | [/doc/0d7ac90d575004c2415/www/index.wiki]. |
| 11 | * For the "[/help?cmd=update|fossil update]" and |
| 12 | "[/help?cmd=checkout|fossil checkout]" commands, if a |
| 13 | managed file is removed because it is no longer part of the target |
| 14 | check-in and the directory containing the file is empty after the |
| 15 | file is removed and the directory is not the current working |
| 16 | directory and is not on the [/help?cmd=empty-dirs|empty-dirs] |
| @@ -25,18 +25,18 @@ | |
| 25 | <a name='v2_8'></a> |
| 26 | <h2>Changes for Version 2.8 (2019-02-20)</h2> |
| 27 | |
| 28 | * Show cherry-pick merges as dotted lines on the timeline graph. |
| 29 | → The "fossil rebuild" command must be run to create and |
| 30 | populate the new "cherrypick" table in the repository in order |
| 31 | for this feature to operate. |
| 32 | * Add the ability to associate branches, check-ins, and tags with |
| 33 | specially-named Wiki pages. This gives the ability to better |
| 34 | document branches and tags, and provide more documentation on |
| 35 | check-ins beyond the check-in comment. The associated Wiki is |
| 36 | automatically displayed on /info pages for check-ins, and on |
| 37 | /timeline?r=BRANCH and /timeline?t=TAG pages for branches and |
| 38 | tags. This feature is on by default, but can be disabled in on |
| 39 | the Admin/Wiki page. |
| 40 | * Enhance the repository list page (shown for example by |
| 41 | "fossil all ui") so that it shows the name and last check-in |
| 42 | time for each project. The implementation of the repository |
| @@ -68,11 +68,11 @@ | |
| 68 | * Enhancements to the "amend", "tag", and "reparent" commands, including |
| 69 | adding options --override-date, --override-user, and --dry-run. |
| 70 | * Add the global --comment-format command-line option and the |
| 71 | comment-format setting to control the display of the command-line |
| 72 | timeline. |
| 73 | * Change the "fossil reparent" command so that it only works from |
| 74 | within an active checkout. |
| 75 | * On the /setup_ucap_list, show administrators how many users have |
| 76 | each capability. The counts are a hyperlink to the /setup_ulist |
| 77 | page showing the subset of users that have that capability. |
| 78 | * Provide the ability to redirect all HTTP pages to HTTPS. Formerly |
| @@ -103,11 +103,11 @@ | |
| 103 | User capabilities are now letters in [a-zA-Z0-9]. |
| 104 | * The built-in skins are now responsive, providing better layout on |
| 105 | small screens, including mobile devices. |
| 106 | * The default skin now includes a hamburger menu that is generated |
| 107 | by the [/sitemap] page. |
| 108 | * All of the built-in skins now use a |
| 109 | [https://en.wikipedia.org/wiki/Content_Security_Policy|Content Security Policy (CSP)] |
| 110 | to help prevent cross-site injection and forgery attacks. There are no known |
| 111 | vulnerabilities in Fossil. The added CSP does not fix anything; it merely adds |
| 112 | another layer of defense. |
| 113 | * The [/sitemap] and other list pages show as multiple columns if |
| 114 |
+1
-1
| --- www/env-opts.md | ||
| +++ www/env-opts.md | ||
| @@ -31,11 +31,11 @@ | ||
| 31 | 31 | |
| 32 | 32 | `--chdir DIRECTORY`: Change to the named directory before processing |
| 33 | 33 | any commands. |
| 34 | 34 | |
| 35 | 35 | |
| 36 | -`--comfmtflags NUMBER` | |
| 36 | +`--comfmtflags NUMBER` | |
| 37 | 37 | `--comment-format NUMBER`: Specify flags that control how check-in comments |
| 38 | 38 | and certain other text outputs are formatted for display. The flags are |
| 39 | 39 | individual bits in `NUMBER`, which must be specified in base 10: |
| 40 | 40 | |
| 41 | 41 | * _0_ — Uses the revised algorithm with no special handling. |
| 42 | 42 |
| --- www/env-opts.md | |
| +++ www/env-opts.md | |
| @@ -31,11 +31,11 @@ | |
| 31 | |
| 32 | `--chdir DIRECTORY`: Change to the named directory before processing |
| 33 | any commands. |
| 34 | |
| 35 | |
| 36 | `--comfmtflags NUMBER` |
| 37 | `--comment-format NUMBER`: Specify flags that control how check-in comments |
| 38 | and certain other text outputs are formatted for display. The flags are |
| 39 | individual bits in `NUMBER`, which must be specified in base 10: |
| 40 | |
| 41 | * _0_ — Uses the revised algorithm with no special handling. |
| 42 |
| --- www/env-opts.md | |
| +++ www/env-opts.md | |
| @@ -31,11 +31,11 @@ | |
| 31 | |
| 32 | `--chdir DIRECTORY`: Change to the named directory before processing |
| 33 | any commands. |
| 34 | |
| 35 | |
| 36 | `--comfmtflags NUMBER` |
| 37 | `--comment-format NUMBER`: Specify flags that control how check-in comments |
| 38 | and certain other text outputs are formatted for display. The flags are |
| 39 | individual bits in `NUMBER`, which must be specified in base 10: |
| 40 | |
| 41 | * _0_ — Uses the revised algorithm with no special handling. |
| 42 |
+2
-2
| --- www/fileformat.wiki | ||
| +++ www/fileformat.wiki | ||
| @@ -529,11 +529,11 @@ | ||
| 529 | 529 | The <b>Z</b> card is the required checksum over the rest of the artifact. |
| 530 | 530 | |
| 531 | 531 | <a name="forum"></a> |
| 532 | 532 | <h3>2.8 Forum Posts</h3> |
| 533 | 533 | |
| 534 | -Forum posts are intended as a mechanism for users and developers to | |
| 534 | +Forum posts are intended as a mechanism for users and developers to | |
| 535 | 535 | discuss a project. Forum posts are like messages on a mailing list. |
| 536 | 536 | |
| 537 | 537 | The following cards are allowed on an forum post artifact: |
| 538 | 538 | |
| 539 | 539 | <blockquote> |
| @@ -547,11 +547,11 @@ | ||
| 547 | 547 | <b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br /> |
| 548 | 548 | <b>Z</b> <i>checksum</i> |
| 549 | 549 | </blockquote> |
| 550 | 550 | |
| 551 | 551 | Every forum post must have either one <b>I</b> card and one <b>G</b> card |
| 552 | -or one <b>H</b> card. | |
| 552 | +or one <b>H</b> card. | |
| 553 | 553 | Forum posts are organized into topic threads. The initial |
| 554 | 554 | post for a thread (the root post) has an <b>H</b> card giving the title or |
| 555 | 555 | subject for that thread. The argument to the <b>H</b> card is a string |
| 556 | 556 | in the same format as a comment string in a <b>C</b> card. |
| 557 | 557 | All follow-up posts have an <b>I</b> card that |
| 558 | 558 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -529,11 +529,11 @@ | |
| 529 | The <b>Z</b> card is the required checksum over the rest of the artifact. |
| 530 | |
| 531 | <a name="forum"></a> |
| 532 | <h3>2.8 Forum Posts</h3> |
| 533 | |
| 534 | Forum posts are intended as a mechanism for users and developers to |
| 535 | discuss a project. Forum posts are like messages on a mailing list. |
| 536 | |
| 537 | The following cards are allowed on an forum post artifact: |
| 538 | |
| 539 | <blockquote> |
| @@ -547,11 +547,11 @@ | |
| 547 | <b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br /> |
| 548 | <b>Z</b> <i>checksum</i> |
| 549 | </blockquote> |
| 550 | |
| 551 | Every forum post must have either one <b>I</b> card and one <b>G</b> card |
| 552 | or one <b>H</b> card. |
| 553 | Forum posts are organized into topic threads. The initial |
| 554 | post for a thread (the root post) has an <b>H</b> card giving the title or |
| 555 | subject for that thread. The argument to the <b>H</b> card is a string |
| 556 | in the same format as a comment string in a <b>C</b> card. |
| 557 | All follow-up posts have an <b>I</b> card that |
| 558 |
| --- www/fileformat.wiki | |
| +++ www/fileformat.wiki | |
| @@ -529,11 +529,11 @@ | |
| 529 | The <b>Z</b> card is the required checksum over the rest of the artifact. |
| 530 | |
| 531 | <a name="forum"></a> |
| 532 | <h3>2.8 Forum Posts</h3> |
| 533 | |
| 534 | Forum posts are intended as a mechanism for users and developers to |
| 535 | discuss a project. Forum posts are like messages on a mailing list. |
| 536 | |
| 537 | The following cards are allowed on an forum post artifact: |
| 538 | |
| 539 | <blockquote> |
| @@ -547,11 +547,11 @@ | |
| 547 | <b>W</b> <i>size</i> <b>\n</b> <i>text</i> <b>\n</b><br /> |
| 548 | <b>Z</b> <i>checksum</i> |
| 549 | </blockquote> |
| 550 | |
| 551 | Every forum post must have either one <b>I</b> card and one <b>G</b> card |
| 552 | or one <b>H</b> card. |
| 553 | Forum posts are organized into topic threads. The initial |
| 554 | post for a thread (the root post) has an <b>H</b> card giving the title or |
| 555 | subject for that thread. The argument to the <b>H</b> card is a string |
| 556 | in the same format as a comment string in a <b>C</b> card. |
| 557 | All follow-up posts have an <b>I</b> card that |
| 558 |
+1
-1
| --- www/forum.wiki | ||
| +++ www/forum.wiki | ||
| @@ -66,11 +66,11 @@ | ||
| 66 | 66 | * <b>Interlink with Other Fossil-Managed Artifacts:</b> Because forum |
| 67 | 67 | posts are normal Fossil artifacts, you can interlink them with |
| 68 | 68 | other Fossil artifacts using short internal links: link to forum |
| 69 | 69 | threads from a [./tickets.wiki | ticket], link to a wiki document |
| 70 | 70 | from a forum post, etc. |
| 71 | - | |
| 71 | + | |
| 72 | 72 | * <b>Durable Links:</b> Once you create a valid internal artifact |
| 73 | 73 | link in Fossil, it <em>remains</em> valid, durably. With |
| 74 | 74 | third-party forum software and mailing list search engines, your |
| 75 | 75 | links are only valid until the third-party component changes its |
| 76 | 76 | URL scheme or disappears from the web. |
| 77 | 77 |
| --- www/forum.wiki | |
| +++ www/forum.wiki | |
| @@ -66,11 +66,11 @@ | |
| 66 | * <b>Interlink with Other Fossil-Managed Artifacts:</b> Because forum |
| 67 | posts are normal Fossil artifacts, you can interlink them with |
| 68 | other Fossil artifacts using short internal links: link to forum |
| 69 | threads from a [./tickets.wiki | ticket], link to a wiki document |
| 70 | from a forum post, etc. |
| 71 | |
| 72 | * <b>Durable Links:</b> Once you create a valid internal artifact |
| 73 | link in Fossil, it <em>remains</em> valid, durably. With |
| 74 | third-party forum software and mailing list search engines, your |
| 75 | links are only valid until the third-party component changes its |
| 76 | URL scheme or disappears from the web. |
| 77 |
| --- www/forum.wiki | |
| +++ www/forum.wiki | |
| @@ -66,11 +66,11 @@ | |
| 66 | * <b>Interlink with Other Fossil-Managed Artifacts:</b> Because forum |
| 67 | posts are normal Fossil artifacts, you can interlink them with |
| 68 | other Fossil artifacts using short internal links: link to forum |
| 69 | threads from a [./tickets.wiki | ticket], link to a wiki document |
| 70 | from a forum post, etc. |
| 71 | |
| 72 | * <b>Durable Links:</b> Once you create a valid internal artifact |
| 73 | link in Fossil, it <em>remains</em> valid, durably. With |
| 74 | third-party forum software and mailing list search engines, your |
| 75 | links are only valid until the third-party component changes its |
| 76 | URL scheme or disappears from the web. |
| 77 |
+2
-2
| --- www/makefile.wiki | ||
| +++ www/makefile.wiki | ||
| @@ -99,13 +99,13 @@ | ||
| 99 | 99 | There is an option code verification step implemented using |
| 100 | 100 | |
| 101 | 101 | 15. [/file/src/codecheck1.c | codecheck1.c] |
| 102 | 102 | |
| 103 | 103 | This file implements a small utility program ("codecheck1") |
| 104 | -that scans other Fossil source files looking for errors in printf-style | |
| 104 | +that scans other Fossil source files looking for errors in printf-style | |
| 105 | 105 | format strings. |
| 106 | -The codecheck1 utility detects missing or surplus arguments on | |
| 106 | +The codecheck1 utility detects missing or surplus arguments on | |
| 107 | 107 | printf-like functions and dangerous uses of "%s" that might |
| 108 | 108 | permit SQL injection or cross-site scripting attacks. This code |
| 109 | 109 | check step is run automatically on each build of Fossil, and can |
| 110 | 110 | also be run separately by typing "make codecheck". Note that the |
| 111 | 111 | built-in printf format checking of GCC does not function for Fossil |
| 112 | 112 |
| --- www/makefile.wiki | |
| +++ www/makefile.wiki | |
| @@ -99,13 +99,13 @@ | |
| 99 | There is an option code verification step implemented using |
| 100 | |
| 101 | 15. [/file/src/codecheck1.c | codecheck1.c] |
| 102 | |
| 103 | This file implements a small utility program ("codecheck1") |
| 104 | that scans other Fossil source files looking for errors in printf-style |
| 105 | format strings. |
| 106 | The codecheck1 utility detects missing or surplus arguments on |
| 107 | printf-like functions and dangerous uses of "%s" that might |
| 108 | permit SQL injection or cross-site scripting attacks. This code |
| 109 | check step is run automatically on each build of Fossil, and can |
| 110 | also be run separately by typing "make codecheck". Note that the |
| 111 | built-in printf format checking of GCC does not function for Fossil |
| 112 |
| --- www/makefile.wiki | |
| +++ www/makefile.wiki | |
| @@ -99,13 +99,13 @@ | |
| 99 | There is an option code verification step implemented using |
| 100 | |
| 101 | 15. [/file/src/codecheck1.c | codecheck1.c] |
| 102 | |
| 103 | This file implements a small utility program ("codecheck1") |
| 104 | that scans other Fossil source files looking for errors in printf-style |
| 105 | format strings. |
| 106 | The codecheck1 utility detects missing or surplus arguments on |
| 107 | printf-like functions and dangerous uses of "%s" that might |
| 108 | permit SQL injection or cross-site scripting attacks. This code |
| 109 | check step is run automatically on each build of Fossil, and can |
| 110 | also be run separately by typing "make codecheck". Note that the |
| 111 | built-in printf format checking of GCC does not function for Fossil |
| 112 |
+10
-10
| --- www/tls-nginx.md | ||
| +++ www/tls-nginx.md | ||
| @@ -59,11 +59,11 @@ | ||
| 59 | 59 | choose in this guide not to make nginx reinterpret Fossil’s |
| 60 | 60 | implementation of HTTP. |
| 61 | 61 | |
| 62 | 62 | * **CGI** — This method is simple but inefficient, because it launches |
| 63 | 63 | a separate Fossil instance on every HTTP hit. |
| 64 | - | |
| 64 | + | |
| 65 | 65 | Since Fossil is a relatively small self-contained program, and it’s |
| 66 | 66 | designed to start up quickly, this method can work well in a |
| 67 | 67 | surprisingly large number of cases. |
| 68 | 68 | |
| 69 | 69 | Nevertheless, we will avoid this option in this document because |
| @@ -233,29 +233,29 @@ | ||
| 233 | 233 | |
| 234 | 234 | Here’s an example configuration: |
| 235 | 235 | |
| 236 | 236 | server { |
| 237 | 237 | server_name .foo.net; |
| 238 | - | |
| 238 | + | |
| 239 | 239 | include local/tls-common; |
| 240 | - | |
| 240 | + | |
| 241 | 241 | charset utf-8; |
| 242 | - | |
| 242 | + | |
| 243 | 243 | access_log /var/log/nginx/foo.net-https-access.log; |
| 244 | 244 | error_log /var/log/nginx/foo.net-https-error.log; |
| 245 | - | |
| 245 | + | |
| 246 | 246 | # Bypass Fossil for the static Doxygen docs |
| 247 | 247 | location /doc/html { |
| 248 | 248 | root /var/www/foo.net; |
| 249 | - | |
| 249 | + | |
| 250 | 250 | location ~* \.(html|ico|css|js|gif|jpg|png)$ { |
| 251 | 251 | expires 7d; |
| 252 | 252 | add_header Vary Accept-Encoding; |
| 253 | 253 | access_log off; |
| 254 | 254 | } |
| 255 | 255 | } |
| 256 | - | |
| 256 | + | |
| 257 | 257 | # Redirect everything else to the Fossil instance |
| 258 | 258 | location / { |
| 259 | 259 | include scgi_params; |
| 260 | 260 | scgi_pass 127.0.0.1:12345; |
| 261 | 261 | scgi_param HTTPS "on"; |
| @@ -301,11 +301,11 @@ | ||
| 301 | 301 | the standard HTTPS port. It is the same as `listen 443; ssl on;` in |
| 302 | 302 | older versions of nginx. |
| 303 | 303 | |
| 304 | 304 | Since all of those domains share a single TLS certificate, we reference |
| 305 | 305 | the same `example.com/*.pem` files written out by Certbot with the |
| 306 | -`ssl_certificate*` lines. | |
| 306 | +`ssl_certificate*` lines. | |
| 307 | 307 | |
| 308 | 308 | The `ssl_dhparam` directive isn’t strictly required, but without it, the |
| 309 | 309 | server becomes vulnerable to the [Logjam attack][lja] because some of |
| 310 | 310 | the cryptography steps are precomputed, making the attacker’s job much |
| 311 | 311 | easier. The parameter file this directive references should be |
| @@ -375,15 +375,15 @@ | ||
| 375 | 375 | So, from the second `service { }` block, we include this file to set up |
| 376 | 376 | the minimal HTTP service we reqiure, `local/http-certbot-only`: |
| 377 | 377 | |
| 378 | 378 | listen 80; |
| 379 | 379 | listen [::]:80; |
| 380 | - | |
| 380 | + | |
| 381 | 381 | # This is expressed as a rewrite rule instead of an "if" because |
| 382 | 382 | # http://wiki.nginx.org/IfIsEvil |
| 383 | 383 | #rewrite ^(/.well-known/acme-challenge/.*) $1 break; |
| 384 | - | |
| 384 | + | |
| 385 | 385 | # Force everything else to HTTPS with a permanent redirect. |
| 386 | 386 | #return 301 https://$host$request_uri; |
| 387 | 387 | |
| 388 | 388 | As written above, this configuration does nothing other than to tell |
| 389 | 389 | nginx that it’s allowed to serve content via HTTP on port 80 as well. |
| 390 | 390 |
| --- www/tls-nginx.md | |
| +++ www/tls-nginx.md | |
| @@ -59,11 +59,11 @@ | |
| 59 | choose in this guide not to make nginx reinterpret Fossil’s |
| 60 | implementation of HTTP. |
| 61 | |
| 62 | * **CGI** — This method is simple but inefficient, because it launches |
| 63 | a separate Fossil instance on every HTTP hit. |
| 64 | |
| 65 | Since Fossil is a relatively small self-contained program, and it’s |
| 66 | designed to start up quickly, this method can work well in a |
| 67 | surprisingly large number of cases. |
| 68 | |
| 69 | Nevertheless, we will avoid this option in this document because |
| @@ -233,29 +233,29 @@ | |
| 233 | |
| 234 | Here’s an example configuration: |
| 235 | |
| 236 | server { |
| 237 | server_name .foo.net; |
| 238 | |
| 239 | include local/tls-common; |
| 240 | |
| 241 | charset utf-8; |
| 242 | |
| 243 | access_log /var/log/nginx/foo.net-https-access.log; |
| 244 | error_log /var/log/nginx/foo.net-https-error.log; |
| 245 | |
| 246 | # Bypass Fossil for the static Doxygen docs |
| 247 | location /doc/html { |
| 248 | root /var/www/foo.net; |
| 249 | |
| 250 | location ~* \.(html|ico|css|js|gif|jpg|png)$ { |
| 251 | expires 7d; |
| 252 | add_header Vary Accept-Encoding; |
| 253 | access_log off; |
| 254 | } |
| 255 | } |
| 256 | |
| 257 | # Redirect everything else to the Fossil instance |
| 258 | location / { |
| 259 | include scgi_params; |
| 260 | scgi_pass 127.0.0.1:12345; |
| 261 | scgi_param HTTPS "on"; |
| @@ -301,11 +301,11 @@ | |
| 301 | the standard HTTPS port. It is the same as `listen 443; ssl on;` in |
| 302 | older versions of nginx. |
| 303 | |
| 304 | Since all of those domains share a single TLS certificate, we reference |
| 305 | the same `example.com/*.pem` files written out by Certbot with the |
| 306 | `ssl_certificate*` lines. |
| 307 | |
| 308 | The `ssl_dhparam` directive isn’t strictly required, but without it, the |
| 309 | server becomes vulnerable to the [Logjam attack][lja] because some of |
| 310 | the cryptography steps are precomputed, making the attacker’s job much |
| 311 | easier. The parameter file this directive references should be |
| @@ -375,15 +375,15 @@ | |
| 375 | So, from the second `service { }` block, we include this file to set up |
| 376 | the minimal HTTP service we reqiure, `local/http-certbot-only`: |
| 377 | |
| 378 | listen 80; |
| 379 | listen [::]:80; |
| 380 | |
| 381 | # This is expressed as a rewrite rule instead of an "if" because |
| 382 | # http://wiki.nginx.org/IfIsEvil |
| 383 | #rewrite ^(/.well-known/acme-challenge/.*) $1 break; |
| 384 | |
| 385 | # Force everything else to HTTPS with a permanent redirect. |
| 386 | #return 301 https://$host$request_uri; |
| 387 | |
| 388 | As written above, this configuration does nothing other than to tell |
| 389 | nginx that it’s allowed to serve content via HTTP on port 80 as well. |
| 390 |
| --- www/tls-nginx.md | |
| +++ www/tls-nginx.md | |
| @@ -59,11 +59,11 @@ | |
| 59 | choose in this guide not to make nginx reinterpret Fossil’s |
| 60 | implementation of HTTP. |
| 61 | |
| 62 | * **CGI** — This method is simple but inefficient, because it launches |
| 63 | a separate Fossil instance on every HTTP hit. |
| 64 | |
| 65 | Since Fossil is a relatively small self-contained program, and it’s |
| 66 | designed to start up quickly, this method can work well in a |
| 67 | surprisingly large number of cases. |
| 68 | |
| 69 | Nevertheless, we will avoid this option in this document because |
| @@ -233,29 +233,29 @@ | |
| 233 | |
| 234 | Here’s an example configuration: |
| 235 | |
| 236 | server { |
| 237 | server_name .foo.net; |
| 238 | |
| 239 | include local/tls-common; |
| 240 | |
| 241 | charset utf-8; |
| 242 | |
| 243 | access_log /var/log/nginx/foo.net-https-access.log; |
| 244 | error_log /var/log/nginx/foo.net-https-error.log; |
| 245 | |
| 246 | # Bypass Fossil for the static Doxygen docs |
| 247 | location /doc/html { |
| 248 | root /var/www/foo.net; |
| 249 | |
| 250 | location ~* \.(html|ico|css|js|gif|jpg|png)$ { |
| 251 | expires 7d; |
| 252 | add_header Vary Accept-Encoding; |
| 253 | access_log off; |
| 254 | } |
| 255 | } |
| 256 | |
| 257 | # Redirect everything else to the Fossil instance |
| 258 | location / { |
| 259 | include scgi_params; |
| 260 | scgi_pass 127.0.0.1:12345; |
| 261 | scgi_param HTTPS "on"; |
| @@ -301,11 +301,11 @@ | |
| 301 | the standard HTTPS port. It is the same as `listen 443; ssl on;` in |
| 302 | older versions of nginx. |
| 303 | |
| 304 | Since all of those domains share a single TLS certificate, we reference |
| 305 | the same `example.com/*.pem` files written out by Certbot with the |
| 306 | `ssl_certificate*` lines. |
| 307 | |
| 308 | The `ssl_dhparam` directive isn’t strictly required, but without it, the |
| 309 | server becomes vulnerable to the [Logjam attack][lja] because some of |
| 310 | the cryptography steps are precomputed, making the attacker’s job much |
| 311 | easier. The parameter file this directive references should be |
| @@ -375,15 +375,15 @@ | |
| 375 | So, from the second `service { }` block, we include this file to set up |
| 376 | the minimal HTTP service we reqiure, `local/http-certbot-only`: |
| 377 | |
| 378 | listen 80; |
| 379 | listen [::]:80; |
| 380 | |
| 381 | # This is expressed as a rewrite rule instead of an "if" because |
| 382 | # http://wiki.nginx.org/IfIsEvil |
| 383 | #rewrite ^(/.well-known/acme-challenge/.*) $1 break; |
| 384 | |
| 385 | # Force everything else to HTTPS with a permanent redirect. |
| 386 | #return 301 https://$host$request_uri; |
| 387 | |
| 388 | As written above, this configuration does nothing other than to tell |
| 389 | nginx that it’s allowed to serve content via HTTP on port 80 as well. |
| 390 |