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 |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA3-256: |
42bfe9362a1a708c5d9c90cefb735781 |
User & Date: | wyoung 2019-06-19 18:45:02.248 |
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
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. |