Fossil SCM
Reduced redundancy in the new feature set size vs ease of use discussion in fossil-v-git.
Commit
a52e68459fe94ce66f87b1a1c247c859caecff77eacc7231eb9b507af66ce039
Parent
5fe84e7011ba6d9…
1 file changed
+13
-12
+13
-12
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -283,33 +283,34 @@ | ||
| 283 | 283 | how we react to |
| 284 | 284 | [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by |
| 285 | 285 | contributions]. In brief, it's harder to get a new feature into Fossil |
| 286 | 286 | than into Git. |
| 287 | 287 | |
| 288 | -Git's larger feature set size is not a good thing. Git's command line | |
| 288 | +A larger feature set size is not necessarily a good thing. Git's command line | |
| 289 | 289 | interface is famously arcane. Masters of the arcane are able to do |
| 290 | 290 | wizardly things, but only by studying their art deeply for years. This |
| 291 | 291 | strikes us as a good thing only in cases where use of the tool itself is |
| 292 | 292 | the primary point of that user's work. |
| 293 | 293 | |
| 294 | 294 | Most DVCS users are not using a DVCS for its own sake, so we do not want |
| 295 | -the DVCS with the most features but the one that lets us get back to our | |
| 295 | +the DVCS with the most features, we want the one with a more easily | |
| 296 | +internalized behavior set, which we can pick up, use quickly, and then | |
| 297 | +set aside in order to get back to our | |
| 296 | 298 | actual job as quickly as possible. There is some minimal set of features |
| 297 | 299 | required to achieve that, but there is a level beyond which more |
| 298 | -features only slow us down when we're trying to figure out how to get | |
| 299 | -past our latest battle with the DVCS. When the number of features grows | |
| 300 | +features only slow us down while we're learning about the DVCS, as we | |
| 301 | +must plow through documentation on features we're not likely to ever | |
| 302 | +use. When the number of features grows | |
| 300 | 303 | to the point where people of normal motivation cannot spend the time to |
| 301 | 304 | master them all, you make the tool <i>less</i> productive to use. |
| 302 | 305 | |
| 303 | -We believe it's better to have a simpler tool with a more easily | |
| 304 | -internalized behavior set, which you can pick up, use quickly, then set | |
| 305 | -aside in order to get back to your main task: producing the content that | |
| 306 | -you manage in the DVCS. We achieve that by carefully choosing which | |
| 307 | -users to give commit bits to, then which of the feature branches they | |
| 308 | -create to merge down to trunk. | |
| 309 | - | |
| 310 | -Fossil more closely adheres to | |
| 306 | +We achieve this balance between feature set size and ease of use by | |
| 307 | +carefully choosing which users to give commit bits to, then in being | |
| 308 | +choosy about which of the contributed feature branches to merge down to | |
| 309 | +trunk. | |
| 310 | + | |
| 311 | +The end result is that Fossil more closely adheres to | |
| 311 | 312 | [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the |
| 312 | 313 | principle of least astonishment] than Git does. |
| 313 | 314 | |
| 314 | 315 | |
| 315 | 316 | <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> |
| 316 | 317 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -283,33 +283,34 @@ | |
| 283 | how we react to |
| 284 | [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by |
| 285 | contributions]. In brief, it's harder to get a new feature into Fossil |
| 286 | than into Git. |
| 287 | |
| 288 | Git's larger feature set size is not a good thing. Git's command line |
| 289 | interface is famously arcane. Masters of the arcane are able to do |
| 290 | wizardly things, but only by studying their art deeply for years. This |
| 291 | strikes us as a good thing only in cases where use of the tool itself is |
| 292 | the primary point of that user's work. |
| 293 | |
| 294 | Most DVCS users are not using a DVCS for its own sake, so we do not want |
| 295 | the DVCS with the most features but the one that lets us get back to our |
| 296 | actual job as quickly as possible. There is some minimal set of features |
| 297 | required to achieve that, but there is a level beyond which more |
| 298 | features only slow us down when we're trying to figure out how to get |
| 299 | past our latest battle with the DVCS. When the number of features grows |
| 300 | to the point where people of normal motivation cannot spend the time to |
| 301 | master them all, you make the tool <i>less</i> productive to use. |
| 302 | |
| 303 | We believe it's better to have a simpler tool with a more easily |
| 304 | internalized behavior set, which you can pick up, use quickly, then set |
| 305 | aside in order to get back to your main task: producing the content that |
| 306 | you manage in the DVCS. We achieve that by carefully choosing which |
| 307 | users to give commit bits to, then which of the feature branches they |
| 308 | create to merge down to trunk. |
| 309 | |
| 310 | Fossil more closely adheres to |
| 311 | [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the |
| 312 | principle of least astonishment] than Git does. |
| 313 | |
| 314 | |
| 315 | <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> |
| 316 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -283,33 +283,34 @@ | |
| 283 | how we react to |
| 284 | [https://www.jonobacon.com/2012/07/25/building-strong-community-structural-integrity/|drive-by |
| 285 | contributions]. In brief, it's harder to get a new feature into Fossil |
| 286 | than into Git. |
| 287 | |
| 288 | A larger feature set size is not necessarily a good thing. Git's command line |
| 289 | interface is famously arcane. Masters of the arcane are able to do |
| 290 | wizardly things, but only by studying their art deeply for years. This |
| 291 | strikes us as a good thing only in cases where use of the tool itself is |
| 292 | the primary point of that user's work. |
| 293 | |
| 294 | Most DVCS users are not using a DVCS for its own sake, so we do not want |
| 295 | the DVCS with the most features, we want the one with a more easily |
| 296 | internalized behavior set, which we can pick up, use quickly, and then |
| 297 | set aside in order to get back to our |
| 298 | actual job as quickly as possible. There is some minimal set of features |
| 299 | required to achieve that, but there is a level beyond which more |
| 300 | features only slow us down while we're learning about the DVCS, as we |
| 301 | must plow through documentation on features we're not likely to ever |
| 302 | use. When the number of features grows |
| 303 | to the point where people of normal motivation cannot spend the time to |
| 304 | master them all, you make the tool <i>less</i> productive to use. |
| 305 | |
| 306 | We achieve this balance between feature set size and ease of use by |
| 307 | carefully choosing which users to give commit bits to, then in being |
| 308 | choosy about which of the contributed feature branches to merge down to |
| 309 | trunk. |
| 310 | |
| 311 | The end result is that Fossil more closely adheres to |
| 312 | [https://en.wikipedia.org/wiki/Principle_of_least_astonishment|the |
| 313 | principle of least astonishment] than Git does. |
| 314 | |
| 315 | |
| 316 | <h3 id="branches">2.4 Individual Branches vs. The Entire Change History</h3> |
| 317 |