Fossil SCM
Better internal links in www/branching.wiki to the new "How Can Forks Divide Development Effort?" section. Also added a Wikipedia link for "DVCS".
Commit
ed4475299069b70bb8b3a59df231c770b72557cf496535691c542de5e412e7e8
Parent
8a794a5dabdff78…
1 file changed
+8
-6
+8
-6
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -253,14 +253,16 @@ | ||
| 253 | 253 | <br><br> |
| 254 | 254 | Because of this, we recommend that if you're using Fossil in a |
| 255 | 255 | distributed way like this, that check-ins be made only to the master |
| 256 | 256 | or its immediate child repos, and that those further down the chain |
| 257 | 257 | be read-only clones. This is not to say that we repudiate Fossil's |
| 258 | - use as a Distributed Version Control System, just that such use is | |
| 259 | - prone to creating forks, by the nature of distributed development. | |
| 260 | - We hope we've made it clear in this document why forks on long-lived | |
| 261 | - shared working branches are a problem.</p></li> | |
| 258 | + use as a | |
| 259 | + [https://en.wikipedia.org/wiki/Distributed_version_control|Distributed Version Control System], | |
| 260 | + just that such use is | |
| 261 | + prone to creating inadvertent forks by the very nature of distributed development. | |
| 262 | + We make a more complete argument that [#bad-fork|forks on long-lived | |
| 263 | + shared working branches are a problem] below.</p></li> | |
| 262 | 264 | |
| 263 | 265 | <li><p>You've automated Fossil (e.g. with a shell script) and |
| 264 | 266 | forking is a possibility, so you write <b>fossil commit |
| 265 | 267 | --allow-fork</b> commands to prevent Fossil from refusing the |
| 266 | 268 | check-in because it would create a fork. It's better to write such |
| @@ -271,13 +273,13 @@ | ||
| 271 | 273 | </ol> |
| 272 | 274 | |
| 273 | 275 | That leaves only one case where we can recommend use of "--allow-fork" |
| 274 | 276 | by interactive users: when you're working on |
| 275 | 277 | a personal branch so that creating a dual-tipped branch isn't going to |
| 276 | -cause any other user an inconvenience or risk [#bad-fork|forking the development]. | |
| 278 | +cause any other user an inconvenience or risk forking the development. | |
| 277 | 279 | Only one developer is involved, and the fork may be short-lived, so |
| 278 | -there is no risk of inadvertently forking the overall development effort. | |
| 280 | +there is no risk of [#bad-fork|inadvertently forking the overall development effort]. | |
| 279 | 281 | This is a good alternative to branching when you just need to |
| 280 | 282 | temporarily fork the branch's development. It avoids cluttering the |
| 281 | 283 | global branch namespace with short-lived temporary named branches. |
| 282 | 284 | |
| 283 | 285 | There's a common generalization of that case: you're a solo developer, |
| 284 | 286 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -253,14 +253,16 @@ | |
| 253 | <br><br> |
| 254 | Because of this, we recommend that if you're using Fossil in a |
| 255 | distributed way like this, that check-ins be made only to the master |
| 256 | or its immediate child repos, and that those further down the chain |
| 257 | be read-only clones. This is not to say that we repudiate Fossil's |
| 258 | use as a Distributed Version Control System, just that such use is |
| 259 | prone to creating forks, by the nature of distributed development. |
| 260 | We hope we've made it clear in this document why forks on long-lived |
| 261 | shared working branches are a problem.</p></li> |
| 262 | |
| 263 | <li><p>You've automated Fossil (e.g. with a shell script) and |
| 264 | forking is a possibility, so you write <b>fossil commit |
| 265 | --allow-fork</b> commands to prevent Fossil from refusing the |
| 266 | check-in because it would create a fork. It's better to write such |
| @@ -271,13 +273,13 @@ | |
| 271 | </ol> |
| 272 | |
| 273 | That leaves only one case where we can recommend use of "--allow-fork" |
| 274 | by interactive users: when you're working on |
| 275 | a personal branch so that creating a dual-tipped branch isn't going to |
| 276 | cause any other user an inconvenience or risk [#bad-fork|forking the development]. |
| 277 | Only one developer is involved, and the fork may be short-lived, so |
| 278 | there is no risk of inadvertently forking the overall development effort. |
| 279 | This is a good alternative to branching when you just need to |
| 280 | temporarily fork the branch's development. It avoids cluttering the |
| 281 | global branch namespace with short-lived temporary named branches. |
| 282 | |
| 283 | There's a common generalization of that case: you're a solo developer, |
| 284 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -253,14 +253,16 @@ | |
| 253 | <br><br> |
| 254 | Because of this, we recommend that if you're using Fossil in a |
| 255 | distributed way like this, that check-ins be made only to the master |
| 256 | or its immediate child repos, and that those further down the chain |
| 257 | be read-only clones. This is not to say that we repudiate Fossil's |
| 258 | use as a |
| 259 | [https://en.wikipedia.org/wiki/Distributed_version_control|Distributed Version Control System], |
| 260 | just that such use is |
| 261 | prone to creating inadvertent forks by the very nature of distributed development. |
| 262 | We make a more complete argument that [#bad-fork|forks on long-lived |
| 263 | shared working branches are a problem] below.</p></li> |
| 264 | |
| 265 | <li><p>You've automated Fossil (e.g. with a shell script) and |
| 266 | forking is a possibility, so you write <b>fossil commit |
| 267 | --allow-fork</b> commands to prevent Fossil from refusing the |
| 268 | check-in because it would create a fork. It's better to write such |
| @@ -271,13 +273,13 @@ | |
| 273 | </ol> |
| 274 | |
| 275 | That leaves only one case where we can recommend use of "--allow-fork" |
| 276 | by interactive users: when you're working on |
| 277 | a personal branch so that creating a dual-tipped branch isn't going to |
| 278 | cause any other user an inconvenience or risk forking the development. |
| 279 | Only one developer is involved, and the fork may be short-lived, so |
| 280 | there is no risk of [#bad-fork|inadvertently forking the overall development effort]. |
| 281 | This is a good alternative to branching when you just need to |
| 282 | temporarily fork the branch's development. It avoids cluttering the |
| 283 | global branch namespace with short-lived temporary named branches. |
| 284 | |
| 285 | There's a common generalization of that case: you're a solo developer, |
| 286 |