Fossil: Diff

Differences From Artifact [c5d1fa363d]:

File www/concepts.wiki — part of check-in [2572e48b93] at 2024-01-27 15:11:04 on branch inskinerator-modern-backport — Removed redundant h1 tags in wiki docs, duplicating "title" elements that already display in the skin's header area. They take up vertical space without adding any new information. (user: wyoung size: 20566)

To Artifact [bf9e06a5df]:

File www/concepts.wiki — part of check-in [54977e1413] at 2024-02-04 04:29:29 on branch inskinerator-modern-backport — Replaced nearly all explicit uses of the "blockquote" tag in the embedded docs: * Constructs like "<blockquote><pre>" are now simply "<pre>" * Ditto "<blockquote><b>" for command examples, which then allowed me to get rid of explicit "br" elements; pre does that for us. * Where it was used merely to get an indent for a code block, we're now using pre or verbatim instead, depending on whether we need embedded HTML and/or pre-wrap handling. (Not the same thing as the prior item.) In some places, this let us replace use of HTML-escaped code blocks in pre with verbatim equivalents, not needing the escaping, allownig the doc source to read more like the rendered HTML. * Use of blockquotes to get hierarchical indenting is no longer necessary; the skin does that. A good example is indenting ol and ul lists under the parent paragraph; additional manual indenting is no longer necessary. The only remaining instances of "blockquote" under www/ are necessary: # The copyright release doc is plain HTML, without the fossil-doc wrapper, giving it no access to the new skin improvements. # One MD doc wants a blockquote in the middle of a list, and the current parsing rules don't let us use ">" there. # The skinning docs talk about styling blockquote elements at one point; it isn't a use of the tag, it is a prose reference to it. (user: wyoung size: 20474) [more...]

︙			︙
112 113 114 115 116 117 118 ~~119 120 121 122 123~~ 124 ~~125~~ 126 127 128 129 130 131 132	identifier for a blob of data, such as a file. Given any file, it is simple to find the artifact ID for that file. But given an artifact ID, it is computationally intractable to generate a file that will have that same artifact ID. Artifact IDs look something like this: <~~blockquote><b~~> 6089f0b563a9db0a6d90682fe47fd7161ff867c8~~<br>~~ 59712614a1b3ccfd84078a37fa5b606e28434326~~<br>~~ 19dbf73078be9779edd6a0156195e610f81c94f9~~<br>~~ b4104959a67175f02d6b415480be22a239f1f077~~<br>~~ 997c9d6ae03ad114b2b57f04e9eeef17dcb82788 ~~</~~b></blockquot~~e>~~ When referring to an artifact using Fossil, you can use a unique prefix of the artifact ID that is four characters or longer. This saves a lot of typing. When displaying artifact IDs, Fossil will usually only show the first 10 digits since that is normally enough to uniquely identify a file.	\| \| \| \| \| \|	112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132	identifier for a blob of data, such as a file. Given any file, it is simple to find the artifact ID for that file. But given an artifact ID, it is computationally intractable to generate a file that will have that same artifact ID. Artifact IDs look something like this: <pre> 6089f0b563a9db0a6d90682fe47fd7161ff867c8 59712614a1b3ccfd84078a37fa5b606e28434326 19dbf73078be9779edd6a0156195e610f81c94f9 b4104959a67175f02d6b415480be22a239f1f077 997c9d6ae03ad114b2b57f04e9eeef17dcb82788 </pre> When referring to an artifact using Fossil, you can use a unique prefix of the artifact ID that is four characters or longer. This saves a lot of typing. When displaying artifact IDs, Fossil will usually only show the first 10 digits since that is normally enough to uniquely identify a file.
︙			︙
236 237 238 239 240 241 242 ~~243 244 245~~ 246 247 248 249 250 251 252	an upgrade. Running "all rebuild" never hurts, so when upgrading it is a good policy to run it even if it is not strictly necessary. To use Fossil, simply type the name of the executable in your shell, followed by one of the various built-in commands and arguments appropriate for that command. For example: ~~<blockquote><b>~~ fossil help ~~</b></blockquote>~~ In the next section, when we say things like "use the <b>help</b> command" we mean to use the command name "help" as the first token after the name of the Fossil executable, as shown above. <h2 id="workflow">4.0 Workflow</h2>	< \| <	236 237 238 239 240 241 242 243 244 245 246 247 248 249 250	an upgrade. Running "all rebuild" never hurts, so when upgrading it is a good policy to run it even if it is not strictly necessary. To use Fossil, simply type the name of the executable in your shell, followed by one of the various built-in commands and arguments appropriate for that command. For example: <pre>fossil help</pre> In the next section, when we say things like "use the <b>help</b> command" we mean to use the command name "help" as the first token after the name of the Fossil executable, as shown above. <h2 id="workflow">4.0 Workflow</h2>
︙			︙
279 280 281 282 283 284 285 ~~286 287 288 289 290~~ 291 292 293 294 295 296 297	An interesting feature of Fossil is that it supports both autosync and manual-merge work flows. The default setting for Fossil is to be in autosync mode. You can change the autosync setting or check the current autosync setting using commands like: ~~<~~blockquot~~e> ~~<b>~~fossil setting autosync on~~<br>~~ fossil setting autosync off~~<br>~~ ~~<b>~~fossil settings~~</b>~~ </~~blockquot~~e>~~ By default, Fossil runs with autosync mode turned on. The authors finds that projects run more smoothly in autosync mode since autosync helps to prevent pointless forking and merging and helps keeps all collaborators working on exactly the same code rather than on their own personal forks of the code. In the author's view, manual-merge mode should be reserved for disconnected operation.	\| \| \| \| \|	277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295	An interesting feature of Fossil is that it supports both autosync and manual-merge work flows. The default setting for Fossil is to be in autosync mode. You can change the autosync setting or check the current autosync setting using commands like: <pre> fossil setting autosync on fossil setting autosync off fossil settings </pre> By default, Fossil runs with autosync mode turned on. The authors finds that projects run more smoothly in autosync mode since autosync helps to prevent pointless forking and merging and helps keeps all collaborators working on exactly the same code rather than on their own personal forks of the code. In the author's view, manual-merge mode should be reserved for disconnected operation.
︙			︙