Fossil

Check-in [ed447529]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Better internal links in www/branching.wiki to the new "How Can Forks Divide Development Effort?" section. Also added a Wikipedia link for "DVCS".
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: ed4475299069b70bb8b3a59df231c770b72557cf496535691c542de5e412e7e8
User & Date: wyoung 2019-06-21 12:20:26
Context
2019-06-21
12:26
Typo fix check-in: eed1ff61 user: wyoung tags: trunk
12:20
Better internal links in www/branching.wiki to the new "How Can Forks Divide Development Effort?" section. Also added a Wikipedia link for "DVCS". check-in: ed447529 user: wyoung tags: trunk
12:09
Clarified User C's view of the bad-fork situation in branching.wiki. check-in: 8a794a5d user: wyoung tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/branching.wiki.

251
252
253
254
255
256
257


258
259
260

261
262
263
264
265
266
267
268
...
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
    well. It isn't until user A syncs her repo with the
    master repo that an inadvertent fork can be detected.
    <br><br>
    Because of this, we recommend that if you're using Fossil in a
    distributed way like this, that check-ins be made only to the master
    or its immediate child repos, and that those further down the chain
    be read-only clones. This is not to say that we repudiate Fossil's


    use as a Distributed Version Control System, just that such use is
    prone to creating forks, by the nature of distributed development.
    We hope we've made it clear in this document why forks on long-lived

    shared working branches are a problem.</p></li>

    <li><p>You've automated Fossil (e.g. with a shell script) and
    forking is a possibility, so you write <b>fossil commit
    --allow-fork</b> commands to prevent Fossil from refusing the
    check-in because it would create a fork.  It's better to write such
    a script to detect this condition and cope with it (e.g. <b>fossil
    update</b>) but if the alternative is losing information, you may
................................................................................
    feel justified in creating forks that an interactive user must later
    clean up with <b>fossil merge</b> commands.</p></li>
</ol>

That leaves only one case where we can recommend use of "--allow-fork"
by interactive users: when you're working on
a personal branch so that creating a dual-tipped branch isn't going to
cause any other user an inconvenience or risk [#bad-fork|forking the development].
Only one developer is involved, and the fork may be short-lived, so
there is no risk of inadvertently forking the overall development effort.
This is a good alternative to branching when you just need to
temporarily fork the branch's development. It avoids cluttering the
global branch namespace with short-lived temporary named branches.

There's a common generalization of that case: you're a solo developer,
so that the problems with branching vs forking simply don't matter. In
that case, feel free to use "--allow-fork" as much as you like.







>
>
|
|
<
>
|







 







|

|







251
252
253
254
255
256
257
258
259
260
261

262
263
264
265
266
267
268
269
270
...
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
    well. It isn't until user A syncs her repo with the
    master repo that an inadvertent fork can be detected.
    <br><br>
    Because of this, we recommend that if you're using Fossil in a
    distributed way like this, that check-ins be made only to the master
    or its immediate child repos, and that those further down the chain
    be read-only clones. This is not to say that we repudiate Fossil's
    use as a
    [https://en.wikipedia.org/wiki/Distributed_version_control|Distributed Version Control System],
    just that such use is
    prone to creating inadvertent forks by the very nature of distributed development.

    We make a more complete argument that [#bad-fork|forks on long-lived
    shared working branches are a problem] below.</p></li>

    <li><p>You've automated Fossil (e.g. with a shell script) and
    forking is a possibility, so you write <b>fossil commit
    --allow-fork</b> commands to prevent Fossil from refusing the
    check-in because it would create a fork.  It's better to write such
    a script to detect this condition and cope with it (e.g. <b>fossil
    update</b>) but if the alternative is losing information, you may
................................................................................
    feel justified in creating forks that an interactive user must later
    clean up with <b>fossil merge</b> commands.</p></li>
</ol>

That leaves only one case where we can recommend use of "--allow-fork"
by interactive users: when you're working on
a personal branch so that creating a dual-tipped branch isn't going to
cause any other user an inconvenience or risk forking the development.
Only one developer is involved, and the fork may be short-lived, so
there is no risk of [#bad-fork|inadvertently forking the overall development effort].
This is a good alternative to branching when you just need to
temporarily fork the branch's development. It avoids cluttering the
global branch namespace with short-lived temporary named branches.

There's a common generalization of that case: you're a solo developer,
so that the problems with branching vs forking simply don't matter. In
that case, feel free to use "--allow-fork" as much as you like.