Fossil SCM
Added a new section, "Branch Names Need Not Be Unique" to www/branching.wiki.
Commit
42bfe9362a1a708c5d9c90cefb73578124cd8f803cfbb7e859ccb410bc5d8b0f
Parent
b761a72922ab2b0…
1 file changed
+31
+31
| --- www/branching.wiki | ||
| +++ www/branching.wiki | ||
| @@ -378,11 +378,42 @@ | ||
| 378 | 378 | because it has two children in the same branch. Check-in 2 of Figure 5 |
| 379 | 379 | also has two children, but each child is in a different branch, hence in |
| 380 | 380 | Figure 5, check-in 2 is considered a "branch point." |
| 381 | 381 | |
| 382 | 382 | <h2>Differences With Other DVCSes</h2> |
| 383 | + | |
| 384 | +<h3 id="single">Single DAG</h3> | |
| 383 | 385 | |
| 384 | 386 | Fossil keeps all check-ins on a single DAG. Branches are identified with |
| 385 | 387 | tags. This means that check-ins can be freely moved between branches |
| 386 | 388 | simply by altering their tags. |
| 387 | 389 | |
| 388 | 390 | Most other DVCSes maintain a separate DAG for each branch. |
| 391 | + | |
| 392 | +<h3 id="unique">Branch Names Need Not Be Unique</h3> | |
| 393 | + | |
| 394 | +Fossil does not require that branch names be unique, as in some VCSes, | |
| 395 | +most notably Git. Just as with unnamed branches (which we call forks) | |
| 396 | +Fossil resolves such ambiguities using the timestamps on the latest | |
| 397 | +checkin in each branch. If you have two branches named "foo" and you say | |
| 398 | +<b>fossil up foo</b>, you get the tip of the "foo" branch with the most | |
| 399 | +recent checkin. | |
| 400 | + | |
| 401 | +This fact is helpful because it means you can reuse branch names, which | |
| 402 | +is especially useful with utility branches. There are several of these | |
| 403 | +in the SQLite and Fossil repositories: "broken-build," "declined," | |
| 404 | +"mistake," etc. As you might guess from these names, such branch names | |
| 405 | +are used in renaming the tip of one branch to shunt it off away from the | |
| 406 | +mainline of that branch due to some human error. (See <b>fossil | |
| 407 | +amend</b> and the Fossil UI checkin ammendment features.) This is a | |
| 408 | +workaround for Fossil's [./shunning.wiki|normal inability to forget | |
| 409 | +history]: we usually don't want to actually <i>remove</i> history, but | |
| 410 | +would like to sometimes set some of it aside under a new label. | |
| 411 | + | |
| 412 | +Because some VCSes can't cope with duplicate branch names, Fossil | |
| 413 | +collapses such names down on export using the same timestamp based | |
| 414 | +arbitration logic, so that only the branch with the newest checkin gets | |
| 415 | +the branch name in the export. | |
| 416 | + | |
| 417 | +All of the above is true of tags in general, not just branches. | |
| 418 | + | |
| 419 | + | |
| 389 | 420 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -378,11 +378,42 @@ | |
| 378 | because it has two children in the same branch. Check-in 2 of Figure 5 |
| 379 | also has two children, but each child is in a different branch, hence in |
| 380 | Figure 5, check-in 2 is considered a "branch point." |
| 381 | |
| 382 | <h2>Differences With Other DVCSes</h2> |
| 383 | |
| 384 | Fossil keeps all check-ins on a single DAG. Branches are identified with |
| 385 | tags. This means that check-ins can be freely moved between branches |
| 386 | simply by altering their tags. |
| 387 | |
| 388 | Most other DVCSes maintain a separate DAG for each branch. |
| 389 |
| --- www/branching.wiki | |
| +++ www/branching.wiki | |
| @@ -378,11 +378,42 @@ | |
| 378 | because it has two children in the same branch. Check-in 2 of Figure 5 |
| 379 | also has two children, but each child is in a different branch, hence in |
| 380 | Figure 5, check-in 2 is considered a "branch point." |
| 381 | |
| 382 | <h2>Differences With Other DVCSes</h2> |
| 383 | |
| 384 | <h3 id="single">Single DAG</h3> |
| 385 | |
| 386 | Fossil keeps all check-ins on a single DAG. Branches are identified with |
| 387 | tags. This means that check-ins can be freely moved between branches |
| 388 | simply by altering their tags. |
| 389 | |
| 390 | Most other DVCSes maintain a separate DAG for each branch. |
| 391 | |
| 392 | <h3 id="unique">Branch Names Need Not Be Unique</h3> |
| 393 | |
| 394 | Fossil does not require that branch names be unique, as in some VCSes, |
| 395 | most notably Git. Just as with unnamed branches (which we call forks) |
| 396 | Fossil resolves such ambiguities using the timestamps on the latest |
| 397 | checkin in each branch. If you have two branches named "foo" and you say |
| 398 | <b>fossil up foo</b>, you get the tip of the "foo" branch with the most |
| 399 | recent checkin. |
| 400 | |
| 401 | This fact is helpful because it means you can reuse branch names, which |
| 402 | is especially useful with utility branches. There are several of these |
| 403 | in the SQLite and Fossil repositories: "broken-build," "declined," |
| 404 | "mistake," etc. As you might guess from these names, such branch names |
| 405 | are used in renaming the tip of one branch to shunt it off away from the |
| 406 | mainline of that branch due to some human error. (See <b>fossil |
| 407 | amend</b> and the Fossil UI checkin ammendment features.) This is a |
| 408 | workaround for Fossil's [./shunning.wiki|normal inability to forget |
| 409 | history]: we usually don't want to actually <i>remove</i> history, but |
| 410 | would like to sometimes set some of it aside under a new label. |
| 411 | |
| 412 | Because some VCSes can't cope with duplicate branch names, Fossil |
| 413 | collapses such names down on export using the same timestamp based |
| 414 | arbitration logic, so that only the branch with the newest checkin gets |
| 415 | the branch name in the export. |
| 416 | |
| 417 | All of the above is true of tags in general, not just branches. |
| 418 | |
| 419 | |
| 420 |