Fossil

Check-in [42bfe936]
Login

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

Overview
Comment:Added a new section, "Branch Names Need Not Be Unique" to www/branching.wiki.
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: 42bfe9362a1a708c5d9c90cefb73578124cd8f803cfbb7e859ccb410bc5d8b0f
User & Date: wyoung 2019-06-19 18:45:02
Context
2019-06-20
11:10
Added the section "Fixing Forks" to www/branching.wiki, and added an explanatory paragraph about the intentionality of forking. check-in: 2686bad1 user: wyoung tags: trunk
2019-06-19
18:45
Added a new section, "Branch Names Need Not Be Unique" to www/branching.wiki. check-in: 42bfe936 user: wyoung tags: trunk
18:24
Added a link to https://fossil-scm.org/fossil/doc/trunk/www/branching.wiki#branching from the recent changes to the fossil ci "would fork" error message. *Hopefully* this will end the debate. check-in: b761a729 user: wyoung tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/branching.wiki.

376
377
378
379
380
381
382


383
384
385
386
387
388






























Check-in 2 of Figure 3 is considered a "fork"
because it has two children in the same branch.  Check-in 2 of Figure 5
also has two children, but each child is in a different branch, hence in
Figure 5, check-in 2 is considered a "branch point."

<h2>Differences With Other DVCSes</h2>



Fossil keeps all check-ins on a single DAG.  Branches are identified with
tags.  This means that check-ins can be freely moved between branches
simply by altering their tags.

Most other DVCSes maintain a separate DAG for each branch.




































>
>






>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419

Check-in 2 of Figure 3 is considered a "fork"
because it has two children in the same branch.  Check-in 2 of Figure 5
also has two children, but each child is in a different branch, hence in
Figure 5, check-in 2 is considered a "branch point."

<h2>Differences With Other DVCSes</h2>

<h3 id="single">Single DAG</h3>

Fossil keeps all check-ins on a single DAG.  Branches are identified with
tags.  This means that check-ins can be freely moved between branches
simply by altering their tags.

Most other DVCSes maintain a separate DAG for each branch.

<h3 id="unique">Branch Names Need Not Be Unique</h3>

Fossil does not require that branch names be unique, as in some VCSes,
most notably Git. Just as with unnamed branches (which we call forks)
Fossil resolves such ambiguities using the timestamps on the latest
checkin in each branch. If you have two branches named "foo" and you say
<b>fossil up foo</b>, you get the tip of the "foo" branch with the most
recent checkin.

This fact is helpful because it means you can reuse branch names, which
is especially useful with utility branches.  There are several of these
in the SQLite and Fossil repositories: "broken-build," "declined,"
"mistake," etc. As you might guess from these names, such branch names
are used in renaming the tip of one branch to shunt it off away from the
mainline of that branch due to some human error. (See <b>fossil
amend</b> and the Fossil UI checkin ammendment features.) This is a
workaround for Fossil's [./shunning.wiki|normal inability to forget
history]: we usually don't want to actually <i>remove</i> history, but
would like to sometimes set some of it aside under a new label.

Because some VCSes can't cope with duplicate branch names, Fossil
collapses such names down on export using the same timestamp based
arbitration logic, so that only the branch with the newest checkin gets
the branch name in the export.

All of the above is true of tags in general, not just branches.