Fossil SCM
Expanded the "Sync over push" section of fossil-v-git beyond the technology to cover the "why" behind the decision. Moved the Jim McCarthy quote up to be with it.
Commit
69e64183f1d92eac42cd2fd5721e5f553145762a10e8a3be11a77164dea14fd7
Parent
970e9173d472ecc…
1 file changed
+22
-12
+22
-12
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -208,14 +208,28 @@ | ||
| 208 | 208 | up to its parent, those changes are sent exactly as they were |
| 209 | 209 | committed locally. [#history|There is no rebasing mechanism in |
| 210 | 210 | Fossil, on purpose.]</p></li> |
| 211 | 211 | |
| 212 | 212 | <li><p><b>Sync over push:</b> Explicit pushes are uncommon in |
| 213 | - Fossil-based projects; the default is to rely on | |
| 213 | + Fossil-based projects: the default is to rely on | |
| 214 | 214 | [/help?cmd=autosync|autosync mode] instead, in which each commit |
| 215 | - normally syncs immediately to its parent repository, so that | |
| 216 | - explicit pushes are not needed.</p></li> | |
| 215 | + syncs immediately to its parent repository. This is a mode so you | |
| 216 | + can turn it off temporarily when needed, such as when working | |
| 217 | + offline. Fossil is still a truly distributed version control system; | |
| 218 | + it's just that its starting default is to assume you're rarely out | |
| 219 | + of communication with the parent repo. | |
| 220 | + <br><br> | |
| 221 | + This is not merely a reflection of modern always-connected computing | |
| 222 | + environments. It is a conscious decision in direct support of | |
| 223 | + SQLite's cathedral development model: we don't want developers going | |
| 224 | + dark, then showing up weeks later with a massive bolus of changes | |
| 225 | + for us to integrate all at once. | |
| 226 | + [https://en.wikipedia.org/wiki/Jim_McCarthy_(author)|Jim McCarthy] | |
| 227 | + put it well in his book on software project management, | |
| 228 | + <i>[https://www.amazon.com/dp/0735623198/|Dynamics of Software | |
| 229 | + Development]</i>: "[https://www.youtube.com/watch?v=oY6BCHqEbyc|Beware | |
| 230 | + of a guy in a room]."</p></li> | |
| 217 | 231 | |
| 218 | 232 | <li><p><b>Branch names sync:</b> Unlike in Git, branch names are not |
| 219 | 233 | purely local labels. They sync along with everything else, so |
| 220 | 234 | everyone sees the same set of branch names.</p></li> |
| 221 | 235 | |
| @@ -229,19 +243,15 @@ | ||
| 229 | 243 | keep local clones identical to the repository it cloned |
| 230 | 244 | from.</p></li> |
| 231 | 245 | </ul> |
| 232 | 246 | |
| 233 | 247 | Where Git encourages siloed development, Fossil fights against it. |
| 234 | -[https://en.wikipedia.org/wiki/Jim_McCarthy_(author)|Jim McCarthy] put | |
| 235 | -it well in his book on software project management, | |
| 236 | -[https://www.amazon.com/dp/0735623198/|Dynamics of Software | |
| 237 | -Development]: "[https://www.youtube.com/watch?v=oY6BCHqEbyc|Beware of a | |
| 238 | -guy in a room]." Fossil places a lot of emphasis on synchronizing | |
| 239 | -everyone's work and on reporting on the state of the project and the | |
| 240 | -work of its developers, so that everyone — especially the project leader | |
| 241 | -— can maintain a better mental picture of what is happening, leading to | |
| 242 | -better situational awareness. | |
| 248 | +Fossil places a lot of emphasis on synchronizing everyone's work and on | |
| 249 | +reporting on the state of the project and the work of its developers, so | |
| 250 | +that everyone — especially the project leader — can maintain a better | |
| 251 | +mental picture of what is happening, leading to better situational | |
| 252 | +awareness. | |
| 243 | 253 | |
| 244 | 254 | Each DVCS can be used in the opposite style, but doing so works against |
| 245 | 255 | their low-friction paths. |
| 246 | 256 | |
| 247 | 257 | ² <small><i>Both Fossil and Git support |
| 248 | 258 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -208,14 +208,28 @@ | |
| 208 | up to its parent, those changes are sent exactly as they were |
| 209 | committed locally. [#history|There is no rebasing mechanism in |
| 210 | Fossil, on purpose.]</p></li> |
| 211 | |
| 212 | <li><p><b>Sync over push:</b> Explicit pushes are uncommon in |
| 213 | Fossil-based projects; the default is to rely on |
| 214 | [/help?cmd=autosync|autosync mode] instead, in which each commit |
| 215 | normally syncs immediately to its parent repository, so that |
| 216 | explicit pushes are not needed.</p></li> |
| 217 | |
| 218 | <li><p><b>Branch names sync:</b> Unlike in Git, branch names are not |
| 219 | purely local labels. They sync along with everything else, so |
| 220 | everyone sees the same set of branch names.</p></li> |
| 221 | |
| @@ -229,19 +243,15 @@ | |
| 229 | keep local clones identical to the repository it cloned |
| 230 | from.</p></li> |
| 231 | </ul> |
| 232 | |
| 233 | Where Git encourages siloed development, Fossil fights against it. |
| 234 | [https://en.wikipedia.org/wiki/Jim_McCarthy_(author)|Jim McCarthy] put |
| 235 | it well in his book on software project management, |
| 236 | [https://www.amazon.com/dp/0735623198/|Dynamics of Software |
| 237 | Development]: "[https://www.youtube.com/watch?v=oY6BCHqEbyc|Beware of a |
| 238 | guy in a room]." Fossil places a lot of emphasis on synchronizing |
| 239 | everyone's work and on reporting on the state of the project and the |
| 240 | work of its developers, so that everyone — especially the project leader |
| 241 | — can maintain a better mental picture of what is happening, leading to |
| 242 | better situational awareness. |
| 243 | |
| 244 | Each DVCS can be used in the opposite style, but doing so works against |
| 245 | their low-friction paths. |
| 246 | |
| 247 | ² <small><i>Both Fossil and Git support |
| 248 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -208,14 +208,28 @@ | |
| 208 | up to its parent, those changes are sent exactly as they were |
| 209 | committed locally. [#history|There is no rebasing mechanism in |
| 210 | Fossil, on purpose.]</p></li> |
| 211 | |
| 212 | <li><p><b>Sync over push:</b> Explicit pushes are uncommon in |
| 213 | Fossil-based projects: the default is to rely on |
| 214 | [/help?cmd=autosync|autosync mode] instead, in which each commit |
| 215 | syncs immediately to its parent repository. This is a mode so you |
| 216 | can turn it off temporarily when needed, such as when working |
| 217 | offline. Fossil is still a truly distributed version control system; |
| 218 | it's just that its starting default is to assume you're rarely out |
| 219 | of communication with the parent repo. |
| 220 | <br><br> |
| 221 | This is not merely a reflection of modern always-connected computing |
| 222 | environments. It is a conscious decision in direct support of |
| 223 | SQLite's cathedral development model: we don't want developers going |
| 224 | dark, then showing up weeks later with a massive bolus of changes |
| 225 | for us to integrate all at once. |
| 226 | [https://en.wikipedia.org/wiki/Jim_McCarthy_(author)|Jim McCarthy] |
| 227 | put it well in his book on software project management, |
| 228 | <i>[https://www.amazon.com/dp/0735623198/|Dynamics of Software |
| 229 | Development]</i>: "[https://www.youtube.com/watch?v=oY6BCHqEbyc|Beware |
| 230 | of a guy in a room]."</p></li> |
| 231 | |
| 232 | <li><p><b>Branch names sync:</b> Unlike in Git, branch names are not |
| 233 | purely local labels. They sync along with everything else, so |
| 234 | everyone sees the same set of branch names.</p></li> |
| 235 | |
| @@ -229,19 +243,15 @@ | |
| 243 | keep local clones identical to the repository it cloned |
| 244 | from.</p></li> |
| 245 | </ul> |
| 246 | |
| 247 | Where Git encourages siloed development, Fossil fights against it. |
| 248 | Fossil places a lot of emphasis on synchronizing everyone's work and on |
| 249 | reporting on the state of the project and the work of its developers, so |
| 250 | that everyone — especially the project leader — can maintain a better |
| 251 | mental picture of what is happening, leading to better situational |
| 252 | awareness. |
| 253 | |
| 254 | Each DVCS can be used in the opposite style, but doing so works against |
| 255 | their low-friction paths. |
| 256 | |
| 257 | ² <small><i>Both Fossil and Git support |
| 258 |