Fossil SCM

Merge in latest from main line.

andybradford 2019-10-24 14:30 clone-resume merge

Commit f882d5cb0e4d945fe923515b6c81254c2d6ae68bb32e41c4e99c58b09fc77458

Parent ec26471439ec529…

7 files changed +5 -2 +10 -1 +39 -79 +5 -5 +4 -2 +43 -10 +5 -6

~ src/info.c ~ src/merge.c ~ www/fossil-v-git.wiki ~ www/rebaseharm.md ~ www/server/windows/index.md ~ www/server/windows/service.md ~ www/server/windows/stunnel.md

M src/info.c

+5 -2

		--- src/info.c
		+++ src/info.c
		@@ -830,22 +830,25 @@
830	830	hyperlink_to_user(zOrigUser,zOrigDate," on ");
831	831	hyperlink_to_date(zOrigDate, "</td></tr>");
832	832	}
833	833	if( g.perm.Admin ){
834	834	db_prepare(&q2,
835		- "SELECT rcvfrom.ipaddr, user.login, datetime(rcvfrom.mtime)"
	835	+ "SELECT rcvfrom.ipaddr, user.login, datetime(rcvfrom.mtime),"
	836	+ " blob.rcvid"
836	837	" FROM blob JOIN rcvfrom USING(rcvid) LEFT JOIN user USING(uid)"
837	838	" WHERE blob.rid=%d",
838	839	rid
839	840	);
840	841	if( db_step(&q2)==SQLITE_ROW ){
841	842	const char *zIpAddr = db_column_text(&q2, 0);
842	843	const char *zUser = db_column_text(&q2, 1);
843	844	const char *zDate = db_column_text(&q2, 2);
	845	+ int rcvid = db_column_int(&q2,3);
844	846	if( zUser==0 \|\| zUser[0]==0 ) zUser = "unknown";
845	847	@ <tr><th>Received From:</th>
846		- @ <td>%h(zUser) @ %h(zIpAddr) on %s(zDate)</td></tr>
	848	+ @ <td>%h(zUser) @ %h(zIpAddr) on %s(zDate) \
	849	+ @ (<a href="%R/rcvfrom?rcvid=%d(rcvid)">Rcvid %d(rcvid)</a>)</td></tr>
847	850	}
848	851	db_finalize(&q2);
849	852	}
850	853
851	854	/* Only show links to read wiki pages if the users can read wiki
852	855

	--- src/info.c
	+++ src/info.c
	@@ -830,22 +830,25 @@
830	hyperlink_to_user(zOrigUser,zOrigDate," on ");
831	hyperlink_to_date(zOrigDate, "</td></tr>");
832	}
833	if( g.perm.Admin ){
834	db_prepare(&q2,
835	"SELECT rcvfrom.ipaddr, user.login, datetime(rcvfrom.mtime)"

836	" FROM blob JOIN rcvfrom USING(rcvid) LEFT JOIN user USING(uid)"
837	" WHERE blob.rid=%d",
838	rid
839	);
840	if( db_step(&q2)==SQLITE_ROW ){
841	const char *zIpAddr = db_column_text(&q2, 0);
842	const char *zUser = db_column_text(&q2, 1);
843	const char *zDate = db_column_text(&q2, 2);

844	if( zUser==0 \|\| zUser[0]==0 ) zUser = "unknown";
845	@ <tr><th>Received From:</th>
846	@ <td>%h(zUser) @ %h(zIpAddr) on %s(zDate)</td></tr>

847	}
848	db_finalize(&q2);
849	}
850
851	/* Only show links to read wiki pages if the users can read wiki
852

	--- src/info.c
	+++ src/info.c
	@@ -830,22 +830,25 @@
830	hyperlink_to_user(zOrigUser,zOrigDate," on ");
831	hyperlink_to_date(zOrigDate, "</td></tr>");
832	}
833	if( g.perm.Admin ){
834	db_prepare(&q2,
835	"SELECT rcvfrom.ipaddr, user.login, datetime(rcvfrom.mtime),"
836	" blob.rcvid"
837	" FROM blob JOIN rcvfrom USING(rcvid) LEFT JOIN user USING(uid)"
838	" WHERE blob.rid=%d",
839	rid
840	);
841	if( db_step(&q2)==SQLITE_ROW ){
842	const char *zIpAddr = db_column_text(&q2, 0);
843	const char *zUser = db_column_text(&q2, 1);
844	const char *zDate = db_column_text(&q2, 2);
845	int rcvid = db_column_int(&q2,3);
846	if( zUser==0 \|\| zUser[0]==0 ) zUser = "unknown";
847	@ <tr><th>Received From:</th>
848	@ <td>%h(zUser) @ %h(zIpAddr) on %s(zDate) \
849	@ (<a href="%R/rcvfrom?rcvid=%d(rcvid)">Rcvid %d(rcvid)</a>)</td></tr>
850	}
851	db_finalize(&q2);
852	}
853
854	/* Only show links to read wiki pages if the users can read wiki
855

M src/merge.c

+10 -1

		--- src/merge.c
		+++ src/merge.c
		@@ -195,11 +195,15 @@
195	195	**
196	196	** Only file content is merged. The result continues to use the
197	197	** file and directory names from the current checkout even if those
198	198	** names might have been changed in the branch being merged in.
199	199	**
200		-** Other options:
	200	+** Options:
	201	+**
	202	+** --backout Do a reverse cherrypick merge against VERSION.
	203	+** In other words, back out the changes that were
	204	+** added by VERSION.
201	205	**
202	206	** --baseline BASELINE Use BASELINE as the "pivot" of the merge instead
203	207	** of the nearest common ancestor. This allows
204	208	** a sequence of changes in a branch to be merged
205	209	** without having to merge the entire branch.
		@@ -209,10 +213,15 @@
209	213	** option overrides the "binary-glob" setting.
210	214	**
211	215	** --case-sensitive BOOL Override the case-sensitive setting. If false,
212	216	** files whose names differ only in case are taken
213	217	** to be the same file.
	218	+**
	219	+** --cherrypick Do a cherrypick merge VERSION into the current
	220	+** checkout. A cherrypick merge pulls in the changes
	221	+** of the single check-in VERSION, rather than all
	222	+** changes back to the nearest common ancestor.
214	223	**
215	224	** -f\|--force Force the merge even if it would be a no-op.
216	225	**
217	226	** --force-missing Force the merge even if there is missing content.
218	227	**
219	228

	--- src/merge.c
	+++ src/merge.c
	@@ -195,11 +195,15 @@
195	**
196	** Only file content is merged. The result continues to use the
197	** file and directory names from the current checkout even if those
198	** names might have been changed in the branch being merged in.
199	**
200	** Other options:




201	**
202	** --baseline BASELINE Use BASELINE as the "pivot" of the merge instead
203	** of the nearest common ancestor. This allows
204	** a sequence of changes in a branch to be merged
205	** without having to merge the entire branch.
	@@ -209,10 +213,15 @@
209	** option overrides the "binary-glob" setting.
210	**
211	** --case-sensitive BOOL Override the case-sensitive setting. If false,
212	** files whose names differ only in case are taken
213	** to be the same file.





214	**
215	** -f\|--force Force the merge even if it would be a no-op.
216	**
217	** --force-missing Force the merge even if there is missing content.
218	**
219

	--- src/merge.c
	+++ src/merge.c
	@@ -195,11 +195,15 @@
195	**
196	** Only file content is merged. The result continues to use the
197	** file and directory names from the current checkout even if those
198	** names might have been changed in the branch being merged in.
199	**
200	** Options:
201	**
202	** --backout Do a reverse cherrypick merge against VERSION.
203	** In other words, back out the changes that were
204	** added by VERSION.
205	**
206	** --baseline BASELINE Use BASELINE as the "pivot" of the merge instead
207	** of the nearest common ancestor. This allows
208	** a sequence of changes in a branch to be merged
209	** without having to merge the entire branch.
	@@ -209,10 +213,15 @@
213	** option overrides the "binary-glob" setting.
214	**
215	** --case-sensitive BOOL Override the case-sensitive setting. If false,
216	** files whose names differ only in case are taken
217	** to be the same file.
218	**
219	** --cherrypick Do a cherrypick merge VERSION into the current
220	** checkout. A cherrypick merge pulls in the changes
221	** of the single check-in VERSION, rather than all
222	** changes back to the nearest common ancestor.
223	**
224	** -f\|--force Force the merge even if it would be a no-op.
225	**
226	** --force-missing Force the merge even if there is missing content.
227	**
228

M www/fossil-v-git.wiki

+39 -79

		--- www/fossil-v-git.wiki
		+++ www/fossil-v-git.wiki
		@@ -73,10 +73,31 @@
73	73	access control system].
74	74	These additional capabilities are available for Git as 3rd-party
75	75	add-ons, but with Fossil they are integrated into
76	76	the design. One way to describe Fossil is that it is
77	77	"[https://github.com/ \| GitHub]-in-a-box."
	78	+
	79	+Fossil can do operations over all local repo clones and check-out
	80	+directories with a single command. For example, Fossil lets you say
	81	+<tt>fossil all pull</tt> on a laptop prior to taking it off the network
	82	+hosting those repos. You can sync up to all of the private repos on your
	83	+company network plus those public Internet-hosted repos you use. Whether
	84	+going out for a working lunch or on a transoceanic an airplane trip, one
	85	+command gets you in sync. This works with several other Fossil
	86	+sub-commands, such as <tt>fossil all changes</tt> to get a list of files
	87	+that you forgot to commit prior to the end of your working day, across
	88	+all repos.
	89	+
	90	+Whenever Fossil is told to modify the local checkout in some destructive
	91	+way ([/help?cmd=rm\|fossil rm], [/help?cmd=update\|fossil update],
	92	+[/help?cmd=revert\|fossil revert], etc.) Fossil remembers the prior state
	93	+and is able to return the check-out directory to that state with a
	94	+<tt>fossil undo</tt> command. You cannot undo a commit in Fossil
	95	+([#history \| on purpose!]) but as long as the change remains confined to
	96	+the local check-out directory only, Fossil makes undo
	97	+[https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things\|easier than in
	98	+Git].
78	99
79	100	For developers who choose to self-host projects (rather than using a
80	101	3rd-party service such as GitHub) Fossil is much easier to set up, since
81	102	the stand-alone Fossil executable together with a [./server/any/cgi.md\|2-line CGI script]
82	103	suffice to instantiate a full-featured developer website. To accomplish
		@@ -233,26 +254,27 @@
233	254	SQLite itself aside is SQL code calling into SQLite. The number of lines
234	255	of SQL code in Fossil isn't large by percentage, but since SQL is such
235	256	an expressive, declarative language, it has an outsized contribution to
236	257	Fossil's user-visible functionality.
237	258
238		-Fossil isn't entirely C and SQL code. Its web UI uses JavaScript where
239		-necessary.⁵ The server-side
	259	+Fossil isn't entirely C and SQL code. Its web UI [./javascript.md \|
	260	+uses JavaScript where
	261	+necessary]. The server-side
240	262	UI scripting uses a custom minimal
241	263	[https://en.wikipedia.org/wiki/Tcl\|Tcl] dialect called
242	264	[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md\|TH1], which is
243	265	embedded into Fossil itself. Fossil's build system and test suite are
244		-largely based on Tcl.⁶ All of this is quite portable.
	266	+largely based on Tcl.⁵ All of this is quite portable.
245	267
246	268	About half of Git's code is POSIX C, and about a third is POSIX shell
247	269	code. This is largely why the so-called "Git for Windows" distributions
248	270	(both [https://git-scm.com/download/win\|first-party] and
249	271	[https://gitforwindows.org/\|third-party]) are actually an
250	272	[http://mingw.org/wiki/msys\|MSYS POSIX portability environment] bundled
251	273	with all of the Git stuff, because it would be too painful to port Git
252	274	natively to Windows. Git is a foreign citizen on Windows, speaking to it
253		-only through a translator.⁷
	275	+only through a translator.⁶
254	276
255	277	While Fossil does lean toward POSIX norms when given a choice — LF-only
256	278	line endings are treated as first-class citizens over CR+LF, for example
257	279	— the Windows build of Fossil is truly native.
258	280
		@@ -339,11 +361,11 @@
339	361	[https://www.git-scm.com/docs/git-request-pull\|pull requests] offer
340	362	a low-friction path to accepting
341	363	[https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/\|drive-by
342	364	contributions]. Fossil's closest equivalent is its unique
343	365	[/help?cmd=bundle\|bundle] feature, which requires higher engagement
344		- than firing off a PR.⁸ This difference comes directly from the
	366	+ than firing off a PR.⁷ This difference comes directly from the
345	367	initial designed purpose for each tool: the SQLite project doesn't
346	368	accept outside contributions from previously-unknown developers, but
347	369	the Linux kernel does.</p></li>
348	370
349	371	<li><p><b>No rebasing:</b> When your local repo clone syncs changes
		@@ -515,12 +537,12 @@
515	537
516	538	Both Fossil and Git store history as a directed acyclic graph (DAG)
517	539	of changes, but Git tends to focus more on individual branches of
518	540	the DAG, whereas Fossil puts more emphasis on the entire DAG.
519	541
520		-For example, the default "sync" behavior in Git is to only sync
521		-a single branch, whereas with Fossil the only sync option it to
	542	+For example, the default behavior in Git is to only synchronize
	543	+a single branch, whereas with Fossil the only sync option is to
522	544	sync the entire DAG. Git commands,
523	545	GitHub, and GitLab tend to show only a single branch at
524	546	a time, whereas Fossil usually shows all parallel branches at
525	547	once. Git has commands like "rebase" that help keep all relevant
526	548	changes on a single branch, whereas Fossil encourages a style of
		@@ -709,11 +731,11 @@
709	731	currently 41 lines long, to which you want to add the 600 lines of
710	732	[./branching.wiki \| the branching document]. The equivalent
711	733	documentation in Git is the aggregation of the man pages for the above
712	734	three commands, which is over 1000 lines, much of it mutually redundant.
713	735	(e.g. the <tt>--edit</tt> and <tt>--no-commit</tt> options get
714		-described three different times, each time differently.) Fossil's
	736	+described three times, each time differently.) Fossil's
715	737	documentation is not only more concise, it gives a nice split of brief
716	738	online help and full online documentation.
717	739
718	740
719	741	<h3 id="hash">2.9 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3>
		@@ -725,21 +747,19 @@
725	747	Fossil delivered a new release allowing a clean migration to
726	748	[https://en.wikipedia.org/wiki/SHA-3\|256-bit SHA-3] with
727	749	[./hashpolicy.wiki\|full backwards compatibility] to old SHA-1 based
728	750	repositories.
729	751
730		-Here in mid-2019, that feature is now in every OS and package repository
731		-known to include Fossil so that the next release
732		-(Fossil 2.10) will begin using SHA-3 hashes even on repos currently
733		-limited to SHA-1 for compatibility with Fossil 1.<i>x</i>,
734		-effectively upgrading them to require Fossil 2.1 or newer. This
735		-not only solves the SHAttered problem, it should prevent a reoccurrence
736		-for the foreseeable future. With the current release (Fossil 2.9) only
737		-repositories created before the
738		-transition to Fossil 2 are still using SHA-1, and then only if the
739		-repository's maintainer chose not to switch them into SHA-3 mode some
740		-time over the past 2 years.
	752	+By mid-2019, that feature arrived in every software package repository
	753	+shipping Fossil, the last mover being Debian's stable package repo,
	754	+which has a highly conservative policy on upgrading to new versions.
	755	+With that hurdle run, we were able to change the default hash mode in
	756	+Fossil 2.10 (released 2019-10-04) to require SHA-3 support both for new
	757	+repositories and to create SHA-3 hashes in existing repos, effectively
	758	+upgrading them if they were created with Fossil 1.<i>x</i>. This not
	759	+only solves the SHAttered problem, it should prevent a reoccurrence of
	760	+similar problems for the foreseeable future.
741	761
742	762	Meanwhile, the Git community took until August 2018 to announce
743	763	[https://git-scm.com/docs/hash-function-transition/2.18.0\|their plan]
744	764	for solving the same problem by moving to SHA-256 (a variant of the
745	765	[https://en.wikipedia.org/wiki/SHA-2\|older SHA-2 algorithm]) and until
		@@ -751,64 +771,10 @@
751	771	moved over to a stronger hash algorithm before someone figures out how
752	772	to make use of the weaknesses in the old one. Fossil's developers moved
753	773	on this problem quickly and had a widely-deployed solution to it years
754	774	ago.
755	775
756		-
757		-<h2 id="missing">3.0 Missing Features</h2>
758		-
759		-Although there is a large overlap in capability between Fossil and Git,
760		-there are many areas where one system has a feature that is simply
761		-missing in the other. We covered most of those above, but there
762		-are a few remaining feature differences we haven't gotten to yet.
763		-
764		-
765		-<h3 id="missing-in-git">3.1 Features found in Fossil but missing from Git</h3>
766		-
767		- * <b>The [/help?cmd=all\|fossil all] command</b>
768		-
769		- Fossil keeps track of all repositories and check-outs and allows
770		- operations over all of them with a single command. For example, in
771		- Fossil is possible to request a pull of all repositories on a laptop
772		- from their respective servers, prior to taking the laptop off network.
773		- Or it is possible to do "fossil all changes" to see if there are any
774		- uncommitted changes that were overlooked prior to the end of the workday.
775		-
776		- * <b>The [/help?cmd=undo\|fossil undo] command</b>
777		-
778		- Whenever Fossil is told to modify the local checkout in some
779		- destructive way ([/help?cmd=rm\|fossil rm], [/help?cmd=update\|fossil
780		- update], [/help?cmd=revert\|fossil revert], etc.) Fossil remembers the
781		- prior state and is able to return the local check-out directory to
782		- its prior state with a simple "fossil undo" command. You
783		- [#history\|cannot undo a commit], since writes to the actual
784		- repository — as opposed to the local check-out directory — are more
785		- or less permanent, on purpose, but as long as the change is simply
786		- staged locally, Fossil makes undo
787		- [https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things\|easier than
788		- in Git].
789		-
790		-
791		-<h3 id="missing-in-fossil">3.2 Features found in Git but missing from Fossil</h3>
792		-
793		- * <b>Rebase</b>
794		-
795		- Because of its emphasis on recording history exactly as it happened,
796		- rather than as we would have liked it to happen,
797		- [./rebaseharm.md\|Fossil deliberately omits the "rebase" command].
798		- For those rare
799		- occasions where something like rebase is actually needed, the same
800		- topology can be achieved using cherrypick merges.
801		-
802		- * <b>Push or pull a single branch</b>
803		-
804		- The [/help?cmd=push\|fossil push], [/help?cmd=pull\|fossil pull], and
805		- [/help?cmd=sync\|fossil sync] commands do not provide the capability to
806		- push or pull individual branches. Pushing and pulling in Fossil is
807		- all or nothing. This is in keeping with Fossil's emphasis on maintaining
808		- a complete record and on sharing everything between all developers.
809		-
810	776	<hr/>
811	777
812	778	<h3>Asides and Digressions</h3>
813	779
814	780	<i><small><ol>
		@@ -844,16 +810,10 @@
844	810
845	811	<li><p>This means you can give up waiting for Fossil to be ported to
846	812	the PDP-11, but we remain hopeful that someone may eventually port
847	813	it to [https://en.wikipedia.org/wiki/Z/OS\|z/OS].
848	814
849		- <li><p>We try to keep use of Javascript to a minimum in the web UI,
850		- and we always try to provide sensible fall-backs for those that run
851		- their browsers with Javascript disabled. Some features of the web UI
852		- simply won't run without Javascript, but the UI behavior does
853		- degrade gracefully.
854		-
855	815	<li><p>"Why is there all this Tcl in and around Fossil?" you may
856	816	ask. It is because D. Richard Hipp is a long-time Tcl user and
857	817	contributor. SQLite started out as an embedded database for Tcl
858	818	specifically. ([https://sqlite.org/tclsqlite.html \| [Reference]])
859	819	When he then created Fossil to manage the development of SQLite, it
860	820

	--- www/fossil-v-git.wiki
	+++ www/fossil-v-git.wiki
	@@ -73,10 +73,31 @@
73	access control system].
74	These additional capabilities are available for Git as 3rd-party
75	add-ons, but with Fossil they are integrated into
76	the design. One way to describe Fossil is that it is
77	"[https://github.com/ \| GitHub]-in-a-box."





















78
79	For developers who choose to self-host projects (rather than using a
80	3rd-party service such as GitHub) Fossil is much easier to set up, since
81	the stand-alone Fossil executable together with a [./server/any/cgi.md\|2-line CGI script]
82	suffice to instantiate a full-featured developer website. To accomplish
	@@ -233,26 +254,27 @@
233	SQLite itself aside is SQL code calling into SQLite. The number of lines
234	of SQL code in Fossil isn't large by percentage, but since SQL is such
235	an expressive, declarative language, it has an outsized contribution to
236	Fossil's user-visible functionality.
237
238	Fossil isn't entirely C and SQL code. Its web UI uses JavaScript where
239	necessary.⁵ The server-side

240	UI scripting uses a custom minimal
241	[https://en.wikipedia.org/wiki/Tcl\|Tcl] dialect called
242	[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md\|TH1], which is
243	embedded into Fossil itself. Fossil's build system and test suite are
244	largely based on Tcl.⁶ All of this is quite portable.
245
246	About half of Git's code is POSIX C, and about a third is POSIX shell
247	code. This is largely why the so-called "Git for Windows" distributions
248	(both [https://git-scm.com/download/win\|first-party] and
249	[https://gitforwindows.org/\|third-party]) are actually an
250	[http://mingw.org/wiki/msys\|MSYS POSIX portability environment] bundled
251	with all of the Git stuff, because it would be too painful to port Git
252	natively to Windows. Git is a foreign citizen on Windows, speaking to it
253	only through a translator.⁷
254
255	While Fossil does lean toward POSIX norms when given a choice — LF-only
256	line endings are treated as first-class citizens over CR+LF, for example
257	— the Windows build of Fossil is truly native.
258
	@@ -339,11 +361,11 @@
339	[https://www.git-scm.com/docs/git-request-pull\|pull requests] offer
340	a low-friction path to accepting
341	[https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/\|drive-by
342	contributions]. Fossil's closest equivalent is its unique
343	[/help?cmd=bundle\|bundle] feature, which requires higher engagement
344	than firing off a PR.⁸ This difference comes directly from the
345	initial designed purpose for each tool: the SQLite project doesn't
346	accept outside contributions from previously-unknown developers, but
347	the Linux kernel does.</p></li>
348
349	<li><p><b>No rebasing:</b> When your local repo clone syncs changes
	@@ -515,12 +537,12 @@
515
516	Both Fossil and Git store history as a directed acyclic graph (DAG)
517	of changes, but Git tends to focus more on individual branches of
518	the DAG, whereas Fossil puts more emphasis on the entire DAG.
519
520	For example, the default "sync" behavior in Git is to only sync
521	a single branch, whereas with Fossil the only sync option it to
522	sync the entire DAG. Git commands,
523	GitHub, and GitLab tend to show only a single branch at
524	a time, whereas Fossil usually shows all parallel branches at
525	once. Git has commands like "rebase" that help keep all relevant
526	changes on a single branch, whereas Fossil encourages a style of
	@@ -709,11 +731,11 @@
709	currently 41 lines long, to which you want to add the 600 lines of
710	[./branching.wiki \| the branching document]. The equivalent
711	documentation in Git is the aggregation of the man pages for the above
712	three commands, which is over 1000 lines, much of it mutually redundant.
713	(e.g. the <tt>--edit</tt> and <tt>--no-commit</tt> options get
714	described three different times, each time differently.) Fossil's
715	documentation is not only more concise, it gives a nice split of brief
716	online help and full online documentation.
717
718
719	<h3 id="hash">2.9 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3>
	@@ -725,21 +747,19 @@
725	Fossil delivered a new release allowing a clean migration to
726	[https://en.wikipedia.org/wiki/SHA-3\|256-bit SHA-3] with
727	[./hashpolicy.wiki\|full backwards compatibility] to old SHA-1 based
728	repositories.
729
730	Here in mid-2019, that feature is now in every OS and package repository
731	known to include Fossil so that the next release
732	(Fossil 2.10) will begin using SHA-3 hashes even on repos currently
733	limited to SHA-1 for compatibility with Fossil 1.<i>x</i>,
734	effectively upgrading them to require Fossil 2.1 or newer. This
735	not only solves the SHAttered problem, it should prevent a reoccurrence
736	for the foreseeable future. With the current release (Fossil 2.9) only
737	repositories created before the
738	transition to Fossil 2 are still using SHA-1, and then only if the
739	repository's maintainer chose not to switch them into SHA-3 mode some
740	time over the past 2 years.
741
742	Meanwhile, the Git community took until August 2018 to announce
743	[https://git-scm.com/docs/hash-function-transition/2.18.0\|their plan]
744	for solving the same problem by moving to SHA-256 (a variant of the
745	[https://en.wikipedia.org/wiki/SHA-2\|older SHA-2 algorithm]) and until
	@@ -751,64 +771,10 @@
751	moved over to a stronger hash algorithm before someone figures out how
752	to make use of the weaknesses in the old one. Fossil's developers moved
753	on this problem quickly and had a widely-deployed solution to it years
754	ago.
755
756
757	<h2 id="missing">3.0 Missing Features</h2>
758
759	Although there is a large overlap in capability between Fossil and Git,
760	there are many areas where one system has a feature that is simply
761	missing in the other. We covered most of those above, but there
762	are a few remaining feature differences we haven't gotten to yet.
763
764
765	<h3 id="missing-in-git">3.1 Features found in Fossil but missing from Git</h3>
766
767	* <b>The [/help?cmd=all\|fossil all] command</b>
768
769	Fossil keeps track of all repositories and check-outs and allows
770	operations over all of them with a single command. For example, in
771	Fossil is possible to request a pull of all repositories on a laptop
772	from their respective servers, prior to taking the laptop off network.
773	Or it is possible to do "fossil all changes" to see if there are any
774	uncommitted changes that were overlooked prior to the end of the workday.
775
776	* <b>The [/help?cmd=undo\|fossil undo] command</b>
777
778	Whenever Fossil is told to modify the local checkout in some
779	destructive way ([/help?cmd=rm\|fossil rm], [/help?cmd=update\|fossil
780	update], [/help?cmd=revert\|fossil revert], etc.) Fossil remembers the
781	prior state and is able to return the local check-out directory to
782	its prior state with a simple "fossil undo" command. You
783	[#history\|cannot undo a commit], since writes to the actual
784	repository — as opposed to the local check-out directory — are more
785	or less permanent, on purpose, but as long as the change is simply
786	staged locally, Fossil makes undo
787	[https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things\|easier than
788	in Git].
789
790
791	<h3 id="missing-in-fossil">3.2 Features found in Git but missing from Fossil</h3>
792
793	* <b>Rebase</b>
794
795	Because of its emphasis on recording history exactly as it happened,
796	rather than as we would have liked it to happen,
797	[./rebaseharm.md\|Fossil deliberately omits the "rebase" command].
798	For those rare
799	occasions where something like rebase is actually needed, the same
800	topology can be achieved using cherrypick merges.
801
802	* <b>Push or pull a single branch</b>
803
804	The [/help?cmd=push\|fossil push], [/help?cmd=pull\|fossil pull], and
805	[/help?cmd=sync\|fossil sync] commands do not provide the capability to
806	push or pull individual branches. Pushing and pulling in Fossil is
807	all or nothing. This is in keeping with Fossil's emphasis on maintaining
808	a complete record and on sharing everything between all developers.
809
810	<hr/>
811
812	<h3>Asides and Digressions</h3>
813
814	<i><small><ol>
	@@ -844,16 +810,10 @@
844
845	<li><p>This means you can give up waiting for Fossil to be ported to
846	the PDP-11, but we remain hopeful that someone may eventually port
847	it to [https://en.wikipedia.org/wiki/Z/OS\|z/OS].
848
849	<li><p>We try to keep use of Javascript to a minimum in the web UI,
850	and we always try to provide sensible fall-backs for those that run
851	their browsers with Javascript disabled. Some features of the web UI
852	simply won't run without Javascript, but the UI behavior does
853	degrade gracefully.
854
855	<li><p>"Why is there all this Tcl in and around Fossil?" you may
856	ask. It is because D. Richard Hipp is a long-time Tcl user and
857	contributor. SQLite started out as an embedded database for Tcl
858	specifically. ([https://sqlite.org/tclsqlite.html \| [Reference]])
859	When he then created Fossil to manage the development of SQLite, it
860

	--- www/fossil-v-git.wiki
	+++ www/fossil-v-git.wiki
	@@ -73,10 +73,31 @@
73	access control system].
74	These additional capabilities are available for Git as 3rd-party
75	add-ons, but with Fossil they are integrated into
76	the design. One way to describe Fossil is that it is
77	"[https://github.com/ \| GitHub]-in-a-box."
78
79	Fossil can do operations over all local repo clones and check-out
80	directories with a single command. For example, Fossil lets you say
81	<tt>fossil all pull</tt> on a laptop prior to taking it off the network
82	hosting those repos. You can sync up to all of the private repos on your
83	company network plus those public Internet-hosted repos you use. Whether
84	going out for a working lunch or on a transoceanic an airplane trip, one
85	command gets you in sync. This works with several other Fossil
86	sub-commands, such as <tt>fossil all changes</tt> to get a list of files
87	that you forgot to commit prior to the end of your working day, across
88	all repos.
89
90	Whenever Fossil is told to modify the local checkout in some destructive
91	way ([/help?cmd=rm\|fossil rm], [/help?cmd=update\|fossil update],
92	[/help?cmd=revert\|fossil revert], etc.) Fossil remembers the prior state
93	and is able to return the check-out directory to that state with a
94	<tt>fossil undo</tt> command. You cannot undo a commit in Fossil
95	([#history \| on purpose!]) but as long as the change remains confined to
96	the local check-out directory only, Fossil makes undo
97	[https://git-scm.com/book/en/v2/Git-Basics-Undoing-Things\|easier than in
98	Git].
99
100	For developers who choose to self-host projects (rather than using a
101	3rd-party service such as GitHub) Fossil is much easier to set up, since
102	the stand-alone Fossil executable together with a [./server/any/cgi.md\|2-line CGI script]
103	suffice to instantiate a full-featured developer website. To accomplish
	@@ -233,26 +254,27 @@
254	SQLite itself aside is SQL code calling into SQLite. The number of lines
255	of SQL code in Fossil isn't large by percentage, but since SQL is such
256	an expressive, declarative language, it has an outsized contribution to
257	Fossil's user-visible functionality.
258
259	Fossil isn't entirely C and SQL code. Its web UI [./javascript.md \|
260	uses JavaScript where
261	necessary]. The server-side
262	UI scripting uses a custom minimal
263	[https://en.wikipedia.org/wiki/Tcl\|Tcl] dialect called
264	[https://www.fossil-scm.org/xfer/doc/trunk/www/th1.md\|TH1], which is
265	embedded into Fossil itself. Fossil's build system and test suite are
266	largely based on Tcl.⁵ All of this is quite portable.
267
268	About half of Git's code is POSIX C, and about a third is POSIX shell
269	code. This is largely why the so-called "Git for Windows" distributions
270	(both [https://git-scm.com/download/win\|first-party] and
271	[https://gitforwindows.org/\|third-party]) are actually an
272	[http://mingw.org/wiki/msys\|MSYS POSIX portability environment] bundled
273	with all of the Git stuff, because it would be too painful to port Git
274	natively to Windows. Git is a foreign citizen on Windows, speaking to it
275	only through a translator.⁶
276
277	While Fossil does lean toward POSIX norms when given a choice — LF-only
278	line endings are treated as first-class citizens over CR+LF, for example
279	— the Windows build of Fossil is truly native.
280
	@@ -339,11 +361,11 @@
361	[https://www.git-scm.com/docs/git-request-pull\|pull requests] offer
362	a low-friction path to accepting
363	[https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/\|drive-by
364	contributions]. Fossil's closest equivalent is its unique
365	[/help?cmd=bundle\|bundle] feature, which requires higher engagement
366	than firing off a PR.⁷ This difference comes directly from the
367	initial designed purpose for each tool: the SQLite project doesn't
368	accept outside contributions from previously-unknown developers, but
369	the Linux kernel does.</p></li>
370
371	<li><p><b>No rebasing:</b> When your local repo clone syncs changes
	@@ -515,12 +537,12 @@
537
538	Both Fossil and Git store history as a directed acyclic graph (DAG)
539	of changes, but Git tends to focus more on individual branches of
540	the DAG, whereas Fossil puts more emphasis on the entire DAG.
541
542	For example, the default behavior in Git is to only synchronize
543	a single branch, whereas with Fossil the only sync option is to
544	sync the entire DAG. Git commands,
545	GitHub, and GitLab tend to show only a single branch at
546	a time, whereas Fossil usually shows all parallel branches at
547	once. Git has commands like "rebase" that help keep all relevant
548	changes on a single branch, whereas Fossil encourages a style of
	@@ -709,11 +731,11 @@
731	currently 41 lines long, to which you want to add the 600 lines of
732	[./branching.wiki \| the branching document]. The equivalent
733	documentation in Git is the aggregation of the man pages for the above
734	three commands, which is over 1000 lines, much of it mutually redundant.
735	(e.g. the <tt>--edit</tt> and <tt>--no-commit</tt> options get
736	described three times, each time differently.) Fossil's
737	documentation is not only more concise, it gives a nice split of brief
738	online help and full online documentation.
739
740
741	<h3 id="hash">2.9 Hash Algorithm: SHA-3 vs SHA-2 vs SHA-1</h3>
	@@ -725,21 +747,19 @@
747	Fossil delivered a new release allowing a clean migration to
748	[https://en.wikipedia.org/wiki/SHA-3\|256-bit SHA-3] with
749	[./hashpolicy.wiki\|full backwards compatibility] to old SHA-1 based
750	repositories.
751
752	By mid-2019, that feature arrived in every software package repository
753	shipping Fossil, the last mover being Debian's stable package repo,
754	which has a highly conservative policy on upgrading to new versions.
755	With that hurdle run, we were able to change the default hash mode in
756	Fossil 2.10 (released 2019-10-04) to require SHA-3 support both for new
757	repositories and to create SHA-3 hashes in existing repos, effectively
758	upgrading them if they were created with Fossil 1.<i>x</i>. This not
759	only solves the SHAttered problem, it should prevent a reoccurrence of
760	similar problems for the foreseeable future.


761
762	Meanwhile, the Git community took until August 2018 to announce
763	[https://git-scm.com/docs/hash-function-transition/2.18.0\|their plan]
764	for solving the same problem by moving to SHA-256 (a variant of the
765	[https://en.wikipedia.org/wiki/SHA-2\|older SHA-2 algorithm]) and until
	@@ -751,64 +771,10 @@
771	moved over to a stronger hash algorithm before someone figures out how
772	to make use of the weaknesses in the old one. Fossil's developers moved
773	on this problem quickly and had a widely-deployed solution to it years
774	ago.
775






















































776	<hr/>
777
778	<h3>Asides and Digressions</h3>
779
780	<i><small><ol>
	@@ -844,16 +810,10 @@
810
811	<li><p>This means you can give up waiting for Fossil to be ported to
812	the PDP-11, but we remain hopeful that someone may eventually port
813	it to [https://en.wikipedia.org/wiki/Z/OS\|z/OS].
814






815	<li><p>"Why is there all this Tcl in and around Fossil?" you may
816	ask. It is because D. Richard Hipp is a long-time Tcl user and
817	contributor. SQLite started out as an embedded database for Tcl
818	specifically. ([https://sqlite.org/tclsqlite.html \| [Reference]])
819	When he then created Fossil to manage the development of SQLite, it
820

M www/rebaseharm.md

+5 -5

		--- www/rebaseharm.md
		+++ www/rebaseharm.md
		@@ -238,11 +238,11 @@
238	238
239	239	The common counterargument is that collapsed check-ins represent a
240	240	better world, the ideal we’re striving for. What that argument overlooks
241	241	is that we must throw away valuable information to get there.
242	242
243		-## <a name="empathy"></a>7.1 Individual check-ins support developer empathy
	243	+### <a name="empathy"></a>7.1 Individual check-ins support developer empathy
244	244
245	245	Ideally, future developers of our software can understand every feature
246	246	in it using only context available in the version of the code they start
247	247	work with. Prior to widespread version control, developers had no choice
248	248	but to work that way. Pre-existing codebases could only be understood
		@@ -283,11 +283,11 @@
283	283	that collapses a whole branch’s worth of changes down to a single
284	284	finished feature.
285	285
286	286	[sdm]: ./fossil-v-git.wiki#durable
287	287
288		-## <a name="bisecting"></a>7.2 Bisecting works better on small check-ins
	288	+### <a name="bisecting"></a>7.2 Bisecting works better on small check-ins
289	289
290	290	Git lets a developer write a feature in ten check-ins but collapse it
291	291	down to an eleventh check-in and then deliberately push only that final
292	292	collapsed check-in to the parent repo. Someone else may then do a bisect
293	293	that blames the merged check-in as the source of the problem they’re
		@@ -298,11 +298,11 @@
298	298	Fossil pushes all 11 check-ins to the parent repository by default, so
299	299	that someone doing that bisect sees the complete check-in history, so
300	300	the bisect will point them at the single original check-in that caused
301	301	the problem.
302	302
303		-## <a name="comments"></a>7.3 Multiple check-ins require multiple check-in comments
	303	+### <a name="comments"></a>7.3 Multiple check-ins require multiple check-in comments
304	304
305	305	The more comments you have from a given developer on a given body of
306	306	code, the more concise documentation you have of that developer’s
307	307	thought process. To resume the bisecting example, a developer trying to
308	308	work out what the original developer was thinking with a given change
		@@ -310,11 +310,11 @@
310	310	one check-in out of ten blamed by the “bisect” command was trying to
311	311	accomplish than if they must work that out from the eleventh check-in’s
312	312	comment, which only explains the “clean” version of the collapsed
313	313	feature.
314	314
315		-## <a name="cherrypicking"></a>7.4 Cherry-picks work better with small check-ins
	315	+### <a name="cherrypicking"></a>7.4 Cherry-picks work better with small check-ins
316	316
317	317	While working on a new feature in one branch, you may come across a bug
318	318	in the pre-existing code that you need to fix in order for work on that
319	319	feature to proceed. You could choose to switch briefly back to the
320	320	parent branch, develop the fix there, check it in, then merge the parent
		@@ -352,11 +352,11 @@
352	352	branch. Even if they manage to do their work without error, it takes
353	353	them more time to do the cherry-pick that way.
354	354
355	355	[rh]: https://en.wikipedia.org/wiki/Red_Hat
356	356
357		-## <a name="backouts"></a>7.5 Back-outs also work better with small check-ins
	357	+### <a name="backouts"></a>7.5 Back-outs also work better with small check-ins
358	358
359	359	The inverse of the cherry-pick merge is the back-out merge. If you push
360	360	only a collapsed version of a private working branch up to the parent
361	361	repo, those working from that parent repo cannot automatically back out
362	362	any of the individual check-ins that went into that private branch.
363	363

	--- www/rebaseharm.md
	+++ www/rebaseharm.md
	@@ -238,11 +238,11 @@
238
239	The common counterargument is that collapsed check-ins represent a
240	better world, the ideal we’re striving for. What that argument overlooks
241	is that we must throw away valuable information to get there.
242
243	## <a name="empathy"></a>7.1 Individual check-ins support developer empathy
244
245	Ideally, future developers of our software can understand every feature
246	in it using only context available in the version of the code they start
247	work with. Prior to widespread version control, developers had no choice
248	but to work that way. Pre-existing codebases could only be understood
	@@ -283,11 +283,11 @@
283	that collapses a whole branch’s worth of changes down to a single
284	finished feature.
285
286	[sdm]: ./fossil-v-git.wiki#durable
287
288	## <a name="bisecting"></a>7.2 Bisecting works better on small check-ins
289
290	Git lets a developer write a feature in ten check-ins but collapse it
291	down to an eleventh check-in and then deliberately push only that final
292	collapsed check-in to the parent repo. Someone else may then do a bisect
293	that blames the merged check-in as the source of the problem they’re
	@@ -298,11 +298,11 @@
298	Fossil pushes all 11 check-ins to the parent repository by default, so
299	that someone doing that bisect sees the complete check-in history, so
300	the bisect will point them at the single original check-in that caused
301	the problem.
302
303	## <a name="comments"></a>7.3 Multiple check-ins require multiple check-in comments
304
305	The more comments you have from a given developer on a given body of
306	code, the more concise documentation you have of that developer’s
307	thought process. To resume the bisecting example, a developer trying to
308	work out what the original developer was thinking with a given change
	@@ -310,11 +310,11 @@
310	one check-in out of ten blamed by the “bisect” command was trying to
311	accomplish than if they must work that out from the eleventh check-in’s
312	comment, which only explains the “clean” version of the collapsed
313	feature.
314
315	## <a name="cherrypicking"></a>7.4 Cherry-picks work better with small check-ins
316
317	While working on a new feature in one branch, you may come across a bug
318	in the pre-existing code that you need to fix in order for work on that
319	feature to proceed. You could choose to switch briefly back to the
320	parent branch, develop the fix there, check it in, then merge the parent
	@@ -352,11 +352,11 @@
352	branch. Even if they manage to do their work without error, it takes
353	them more time to do the cherry-pick that way.
354
355	[rh]: https://en.wikipedia.org/wiki/Red_Hat
356
357	## <a name="backouts"></a>7.5 Back-outs also work better with small check-ins
358
359	The inverse of the cherry-pick merge is the back-out merge. If you push
360	only a collapsed version of a private working branch up to the parent
361	repo, those working from that parent repo cannot automatically back out
362	any of the individual check-ins that went into that private branch.
363

	--- www/rebaseharm.md
	+++ www/rebaseharm.md
	@@ -238,11 +238,11 @@
238
239	The common counterargument is that collapsed check-ins represent a
240	better world, the ideal we’re striving for. What that argument overlooks
241	is that we must throw away valuable information to get there.
242
243	### <a name="empathy"></a>7.1 Individual check-ins support developer empathy
244
245	Ideally, future developers of our software can understand every feature
246	in it using only context available in the version of the code they start
247	work with. Prior to widespread version control, developers had no choice
248	but to work that way. Pre-existing codebases could only be understood
	@@ -283,11 +283,11 @@
283	that collapses a whole branch’s worth of changes down to a single
284	finished feature.
285
286	[sdm]: ./fossil-v-git.wiki#durable
287
288	### <a name="bisecting"></a>7.2 Bisecting works better on small check-ins
289
290	Git lets a developer write a feature in ten check-ins but collapse it
291	down to an eleventh check-in and then deliberately push only that final
292	collapsed check-in to the parent repo. Someone else may then do a bisect
293	that blames the merged check-in as the source of the problem they’re
	@@ -298,11 +298,11 @@
298	Fossil pushes all 11 check-ins to the parent repository by default, so
299	that someone doing that bisect sees the complete check-in history, so
300	the bisect will point them at the single original check-in that caused
301	the problem.
302
303	### <a name="comments"></a>7.3 Multiple check-ins require multiple check-in comments
304
305	The more comments you have from a given developer on a given body of
306	code, the more concise documentation you have of that developer’s
307	thought process. To resume the bisecting example, a developer trying to
308	work out what the original developer was thinking with a given change
	@@ -310,11 +310,11 @@
310	one check-in out of ten blamed by the “bisect” command was trying to
311	accomplish than if they must work that out from the eleventh check-in’s
312	comment, which only explains the “clean” version of the collapsed
313	feature.
314
315	### <a name="cherrypicking"></a>7.4 Cherry-picks work better with small check-ins
316
317	While working on a new feature in one branch, you may come across a bug
318	in the pre-existing code that you need to fix in order for work on that
319	feature to proceed. You could choose to switch briefly back to the
320	parent branch, develop the fix there, check it in, then merge the parent
	@@ -352,11 +352,11 @@
352	branch. Even if they manage to do their work without error, it takes
353	them more time to do the cherry-pick that way.
354
355	[rh]: https://en.wikipedia.org/wiki/Red_Hat
356
357	### <a name="backouts"></a>7.5 Back-outs also work better with small check-ins
358
359	The inverse of the cherry-pick merge is the back-out merge. If you push
360	only a collapsed version of a private working branch up to the parent
361	repo, those working from that parent repo cannot automatically back out
362	any of the individual check-ins that went into that private branch.
363

M www/server/windows/index.md

+4 -2

		--- www/server/windows/index.md
		+++ www/server/windows/index.md
		@@ -1,6 +1,8 @@
1	1	# Using Windows as a Fossil Server
2	2
3		-- [Fossil as a Service](service.md)
4		-- [Using stunnel with Fossil on Windows](stunnel.md)
	3	+- [Fossil server command](./none.md)
	4	+- [Fossil as CGI (IIS)](./iis.md)
	5	+- [Fossil as a Service](./service.md)
	6	+- [Using stunnel with Fossil on Windows](./stunnel.md)
5	7
6	8	[Return to the top-level Fossil server article.](../)
7	9

	--- www/server/windows/index.md
	+++ www/server/windows/index.md
	@@ -1,6 +1,8 @@
1	# Using Windows as a Fossil Server
2
3	- [Fossil as a Service](service.md)
4	- [Using stunnel with Fossil on Windows](stunnel.md)


5
6	[Return to the top-level Fossil server article.](../)
7

	--- www/server/windows/index.md
	+++ www/server/windows/index.md
	@@ -1,6 +1,8 @@
1	# Using Windows as a Fossil Server
2
3	- [Fossil server command](./none.md)
4	- [Fossil as CGI (IIS)](./iis.md)
5	- [Fossil as a Service](./service.md)
6	- [Using stunnel with Fossil on Windows](./stunnel.md)
7
8	[Return to the top-level Fossil server article.](../)
9

M www/server/windows/service.md

+43 -10

		--- www/server/windows/service.md
		+++ www/server/windows/service.md
		@@ -10,28 +10,61 @@
10	10
11	11	## Place Fossil on Server
12	12
13	13	However you obtained your copy of Fossil, it is recommended that you follow
14	14	Windows conventions and place it within `\Program Files\FossilSCM`. Since
15		-Fossil 2.10 is a 64bit binary, this is the proper location for the executable. This
16		-way Fossil is in an expected location and you will have minimal issues with
	15	+Fossil 2.10 is a 64bit binary, this is the proper location for the executable.
	16	+This way Fossil is at an expected location and you will have minimal issues with
17	17	Windows interfering in your ability to run Fossil as a service. You will need
18		-Administrative rights to place fossil at the recommended location. You do NOT
19		-need to add this location to the path, though you may do so if you wish.
	18	+Administrative rights to place fossil at the recommended location. If you will
	19	+only be running Fossil as a service, you do not need to add this location to the
	20	+path, though you may do so if you wish.
20	21
21		-## Make Fossil a Windows Service
	22	+## Installing Fossil as a Service
22	23
23	24	Luckily the hard work to use Fossil as a Windows Service has been done by the
24	25	Fossil team. We simply have to install it with the proper command line options.
25	26	Fossil on Windows has a command `fossil winsrv` to allow installing Fossil as a
26		-service on Windows, but the options are limited, so an alternative service
27		-install using PowerShell is documented here. The below should all be entered
28		-as a single line in an Administrative PowerShell console.
	27	+service on Windows. This command is only documented on the windows executable
	28	+of Fossil. You must also run the command as administrator for it to be
	29	+successful.
	30	+
	31	+### Fossil winsrv Example
	32	+
	33	+The simplest form of the command is:
	34	+
	35	+```
	36	+fossil winsrv create --repository D:/Path/to/Repo.fossil
	37	+```
	38	+
	39	+This will create a windows service named 'Fossil-DSCM' running under the local
	40	+system account and accessible on port 8080 by default. `fossil winsrv` can also
	41	+start, stop, and delete the service. For all available options, please execute
	42	+`fossil help winsrv` on a windows install of Fossil.
	43	+
	44	+If you wish to server a directory of repositories, the `fossil winsrv` command
	45	+requires a slightly different set of options vs. `fossil server`:
	46	+
	47	+```
	48	+fossil winsrv create --repository D:/Path/to/Repos --repolist
	49	+```
	50	+
	51	+<a name='PowerShell'></a>
	52	+### Advanced service installation using PowerShell
	53	+
	54	+As great as `fossil winsrv` is, it does not have one to one reflection of all of
	55	+the `fossil server` [options](/help?cmd=server). When you need to use some of
	56	+the more advanced options, such as `--https`, `--skin`, or `--extroot`, you will
	57	+need to use PowerShell to configure and install the Windows service.
	58	+
	59	+PowerShell provides the [New-Service](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/new-service?view=powershell-5.1)
	60	+command, which we can use to install and configure Fossil as a service. The
	61	+below should all be entered as a single line in an Administrative PowerShell
	62	+console.
29	63
30	64	```PowerShell
31		-New-Service -Name fossil -DisplayName fossil -BinaryPathName '"C:\Program Files\FossilSCM\fossil.exe"
32		-server --port 8080 --repolist "D:/Path/to/Repos"' -StartupType Automatic
	65	+New-Service -Name fossil -DisplayName fossil -BinaryPathName '"C:\Program Files\FossilSCM\fossil.exe" server --port 8080 --repolist "D:/Path/to/Repos"' -StartupType Automatic
33	66	```
34	67
35	68	Please note the use of forward slashes in the repolist path passed to Fossil.
36	69	Windows will accept either back slashes or forward slashes in path names, but
37	70	Fossil has a preference for forward slashes. The use of `--repolist` will make
38	71

	--- www/server/windows/service.md
	+++ www/server/windows/service.md
	@@ -10,28 +10,61 @@
10
11	## Place Fossil on Server
12
13	However you obtained your copy of Fossil, it is recommended that you follow
14	Windows conventions and place it within `\Program Files\FossilSCM`. Since
15	Fossil 2.10 is a 64bit binary, this is the proper location for the executable. This
16	way Fossil is in an expected location and you will have minimal issues with
17	Windows interfering in your ability to run Fossil as a service. You will need
18	Administrative rights to place fossil at the recommended location. You do NOT
19	need to add this location to the path, though you may do so if you wish.

20
21	## Make Fossil a Windows Service
22
23	Luckily the hard work to use Fossil as a Windows Service has been done by the
24	Fossil team. We simply have to install it with the proper command line options.
25	Fossil on Windows has a command `fossil winsrv` to allow installing Fossil as a
26	service on Windows, but the options are limited, so an alternative service
27	install using PowerShell is documented here. The below should all be entered
28	as a single line in an Administrative PowerShell console.

































29
30	```PowerShell
31	New-Service -Name fossil -DisplayName fossil -BinaryPathName '"C:\Program Files\FossilSCM\fossil.exe"
32	server --port 8080 --repolist "D:/Path/to/Repos"' -StartupType Automatic
33	```
34
35	Please note the use of forward slashes in the repolist path passed to Fossil.
36	Windows will accept either back slashes or forward slashes in path names, but
37	Fossil has a preference for forward slashes. The use of `--repolist` will make
38

	--- www/server/windows/service.md
	+++ www/server/windows/service.md
	@@ -10,28 +10,61 @@
10
11	## Place Fossil on Server
12
13	However you obtained your copy of Fossil, it is recommended that you follow
14	Windows conventions and place it within `\Program Files\FossilSCM`. Since
15	Fossil 2.10 is a 64bit binary, this is the proper location for the executable.
16	This way Fossil is at an expected location and you will have minimal issues with
17	Windows interfering in your ability to run Fossil as a service. You will need
18	Administrative rights to place fossil at the recommended location. If you will
19	only be running Fossil as a service, you do not need to add this location to the
20	path, though you may do so if you wish.
21
22	## Installing Fossil as a Service
23
24	Luckily the hard work to use Fossil as a Windows Service has been done by the
25	Fossil team. We simply have to install it with the proper command line options.
26	Fossil on Windows has a command `fossil winsrv` to allow installing Fossil as a
27	service on Windows. This command is only documented on the windows executable
28	of Fossil. You must also run the command as administrator for it to be
29	successful.
30
31	### Fossil winsrv Example
32
33	The simplest form of the command is:
34
35	```
36	fossil winsrv create --repository D:/Path/to/Repo.fossil
37	```
38
39	This will create a windows service named 'Fossil-DSCM' running under the local
40	system account and accessible on port 8080 by default. `fossil winsrv` can also
41	start, stop, and delete the service. For all available options, please execute
42	`fossil help winsrv` on a windows install of Fossil.
43
44	If you wish to server a directory of repositories, the `fossil winsrv` command
45	requires a slightly different set of options vs. `fossil server`:
46
47	```
48	fossil winsrv create --repository D:/Path/to/Repos --repolist
49	```
50
51	<a name='PowerShell'></a>
52	### Advanced service installation using PowerShell
53
54	As great as `fossil winsrv` is, it does not have one to one reflection of all of
55	the `fossil server` [options](/help?cmd=server). When you need to use some of
56	the more advanced options, such as `--https`, `--skin`, or `--extroot`, you will
57	need to use PowerShell to configure and install the Windows service.
58
59	PowerShell provides the [New-Service](https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/new-service?view=powershell-5.1)
60	command, which we can use to install and configure Fossil as a service. The
61	below should all be entered as a single line in an Administrative PowerShell
62	console.
63
64	```PowerShell
65	New-Service -Name fossil -DisplayName fossil -BinaryPathName '"C:\Program Files\FossilSCM\fossil.exe" server --port 8080 --repolist "D:/Path/to/Repos"' -StartupType Automatic

66	```
67
68	Please note the use of forward slashes in the repolist path passed to Fossil.
69	Windows will accept either back slashes or forward slashes in path names, but
70	Fossil has a preference for forward slashes. The use of `--repolist` will make
71

M www/server/windows/stunnel.md

+5 -6

		--- www/server/windows/stunnel.md
		+++ www/server/windows/stunnel.md
		@@ -19,18 +19,17 @@
19	19	URLs when used with stunnel as a proxy. Please make sure you are using Fossil
20	20	2.10 or later on Windows.
21	21
22	22	## Configure Fossil Service for https
23	23
24		-Following most of [Fossil as a Windows Service](./service.md), you will need
25		-to change the command to install the Fossil Service to configure it properly for
26		-use with stunnel as an https proxy. Run the following instead:
	24	+Due to the need for the `--https` option for successfully using Fossil with
	25	+stunnel, we will use [Advanced service installation using PowerShell](./service.md#PowerShell).
	26	+We will need to change the command to install the Fossil Service to configure
	27	+it properly for use with stunnel as an https proxy. Run the following:
27	28
28	29	```PowerShell
29		-New-Service -Name fossil-secure -DisplayName fossil-secure -BinaryPathName '"C:\Program Files\FossilSCM\fossil.exe"
30		-server --localhost --port 9000 --https --repolist "D:/Path/to/Repos"' -StartupType Automatic
31		-
	30	+New-Service -Name fossil-secure -DisplayName fossil-secure -BinaryPathName '"C:\Program Files\FossilSCM\fossil.exe" server --localhost --port 9000 --https --repolist "D:/Path/to/Repos"' -StartupType Automatic
32	31	```
33	32
34	33	The use of `--localhost` means Fossil will only listen for traffic on the local
35	34	host on the designated port - 9000 in this case - and will not respond to
36	35	network traffic. Using `--https` will tell Fossil to generate HTTPS URLs rather
37	36

	--- www/server/windows/stunnel.md
	+++ www/server/windows/stunnel.md
	@@ -19,18 +19,17 @@
19	URLs when used with stunnel as a proxy. Please make sure you are using Fossil
20	2.10 or later on Windows.
21
22	## Configure Fossil Service for https
23
24	Following most of [Fossil as a Windows Service](./service.md), you will need
25	to change the command to install the Fossil Service to configure it properly for
26	use with stunnel as an https proxy. Run the following instead:

27
28	```PowerShell
29	New-Service -Name fossil-secure -DisplayName fossil-secure -BinaryPathName '"C:\Program Files\FossilSCM\fossil.exe"
30	server --localhost --port 9000 --https --repolist "D:/Path/to/Repos"' -StartupType Automatic
31
32	```
33
34	The use of `--localhost` means Fossil will only listen for traffic on the local
35	host on the designated port - 9000 in this case - and will not respond to
36	network traffic. Using `--https` will tell Fossil to generate HTTPS URLs rather
37

	--- www/server/windows/stunnel.md
	+++ www/server/windows/stunnel.md
	@@ -19,18 +19,17 @@
19	URLs when used with stunnel as a proxy. Please make sure you are using Fossil
20	2.10 or later on Windows.
21
22	## Configure Fossil Service for https
23
24	Due to the need for the `--https` option for successfully using Fossil with
25	stunnel, we will use [Advanced service installation using PowerShell](./service.md#PowerShell).
26	We will need to change the command to install the Fossil Service to configure
27	it properly for use with stunnel as an https proxy. Run the following:
28
29	```PowerShell
30	New-Service -Name fossil-secure -DisplayName fossil-secure -BinaryPathName '"C:\Program Files\FossilSCM\fossil.exe" server --localhost --port 9000 --https --repolist "D:/Path/to/Repos"' -StartupType Automatic


31	```
32
33	The use of `--localhost` means Fossil will only listen for traffic on the local
34	host on the designated port - 9000 in this case - and will not respond to
35	network traffic. Using `--https` will tell Fossil to generate HTTPS URLs rather
36

Fossil SCM

Keyboard Shortcuts