Fossil SCM
Clarified point 2.6 in fossil-v-git.wiki to address feedback from Hacker News user balfirevic here: https://news.ycombinator.com/item?id=21974942
Commit
f6e04cc4233629b59a5ded9dd488d7e45d247cde75828efc87bbc37c17712fe9
Parent
2af7fedd67c08db…
1 file changed
+28
-16
+28
-16
| --- www/fossil-v-git.wiki | ||
| +++ www/fossil-v-git.wiki | ||
| @@ -562,21 +562,29 @@ | ||
| 562 | 562 | tightly focused and cohesive implementation. |
| 563 | 563 | |
| 564 | 564 | |
| 565 | 565 | <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> |
| 566 | 566 | |
| 567 | -The default mode of operation in Git is to have a single working | |
| 568 | -directory with a single <tt>.git</tt> subdirectory holding the actual | |
| 569 | -local repository contents. | |
| 567 | +Because Git commingles the repository data with the initial checkout of | |
| 568 | +that repository, the default mode of operation in Git is to stick to that | |
| 569 | +single work/repo tree, even when that's a shortsighted way of working. | |
| 570 | 570 | |
| 571 | 571 | Fossil doesn't work that way. A Fossil repository is a SQLite database |
| 572 | -file which is normally stored outside the working directory. You can | |
| 572 | +file which is normally stored outside the working checkout directory. You can | |
| 573 | 573 | [/help?cmd=open | open] a Fossil repository any number of times into |
| 574 | 574 | any number of working directories. A common usage pattern is to have one |
| 575 | 575 | working directory per active working branch, so that switching branches |
| 576 | 576 | is done with a <tt>cd</tt> command rather than by checking out the |
| 577 | 577 | branches successively in a single working directory. |
| 578 | + | |
| 579 | +Fossil does allow you to switch branches within a working checkout | |
| 580 | +directory, and this is also often done. It is simply that there is no | |
| 581 | +inherent penalty to either choice in Fossil as there is in Git. The | |
| 582 | +standard advice is to use a switch-in-place workflow in Fossil when | |
| 583 | +the disturbance from switching branches is small, and to use multiple | |
| 584 | +checkouts when you have long-lived working branches that are different | |
| 585 | +enough that switching in place is disruptive. | |
| 578 | 586 | |
| 579 | 587 | You can use Git in the Fossil style, either by manually symlinking the |
| 580 | 588 | <tt>.git</tt> directory from one working directory to another or by use |
| 581 | 589 | of the <tt>[https://git-scm.com/docs/git-worktree|git-worktree]</tt> |
| 582 | 590 | feature. Nevertheless, Git's default tie between working directory and |
| @@ -583,41 +591,45 @@ | ||
| 583 | 591 | repository means the standard method for working with a Git repo is to |
| 584 | 592 | have one working directory only. Most Git tutorials teach this style, so |
| 585 | 593 | it is how most people learn to use Git. Because relatively few people |
| 586 | 594 | use Git with multiple working directories per repository, there are |
| 587 | 595 | [https://duckduckgo.com/?q=git+worktree+problem | several known |
| 588 | -problems] in working that way, which don't happen in Fossil because of | |
| 596 | +problems] with that way of working, problems which don't happen in Fossil because of | |
| 589 | 597 | the clear separation between repository and working directory. |
| 590 | 598 | |
| 591 | -Switching branches inside a single working directory loses local context | |
| 599 | +This distinction matters because switching branches inside a single working directory loses local context | |
| 592 | 600 | on each switch. |
| 593 | 601 | |
| 594 | 602 | For instance, in any software project where the runnable program must be |
| 595 | 603 | built from source files, you invalidate build objects on each switch, |
| 596 | -artificially increasing the time required to switch versions. This | |
| 604 | +artificially increasing the time required to switch versions. Most obviously, this | |
| 597 | 605 | affects software written in statically-compiled programming languages |
| 598 | 606 | such as C, Java, and Haskell, but it can even affect programs written in |
| 599 | -dynamic languages like JavaScript. A common | |
| 607 | +dynamic languages like JavaScript. A typical | |
| 600 | 608 | [https://en.wikipedia.org/wiki/Single-page_application | SPA] build |
| 601 | -process involves a [http://browserify.org/ | Browserify] pass to convert | |
| 602 | -[https://nodejs.org/ | Node] packages to run in a web browser, | |
| 603 | -[https://sass-lang.com | SASS files] to CSS, | |
| 604 | -[https://www.typescriptlang.org | Typescript] to JavaScript, etc., to | |
| 605 | -say nothing of [https://github.com/mishoo/UglifyJS | uglification] and | |
| 606 | -other passes. Once all that processing work is done for a given input | |
| 609 | +process involves several passes: [http://browserify.org/ | Browserify] to convert | |
| 610 | +[https://nodejs.org/ | Node] packages so they'll run in a web browser, | |
| 611 | +[https://sass-lang.com | SASS] to CSS translation, | |
| 612 | +transpilation of [https://www.typescriptlang.org | Typescript] to JavaScript, | |
| 613 | +[https://github.com/mishoo/UglifyJS | uglification], etc. | |
| 614 | +Once all that processing work is done for a given input | |
| 607 | 615 | file in a given working directory, why re-do that work just to switch |
| 608 | -versions? | |
| 616 | +versions? If most of the files that differ between versions don't change | |
| 617 | +very often, you can save substantial time by switching branches with | |
| 618 | +<tt>cd</tt> rather than swapping versions in-place within a working | |
| 619 | +checkout directory. | |
| 609 | 620 | |
| 610 | 621 | For another example, you might have an active long-running test grinding |
| 611 | 622 | away in a working directory, then get a call from a customer requiring |
| 612 | 623 | that you switch to a stable branch to answer questions in terms of the |
| 613 | 624 | version that customer is running. You don't want to stop the test in |
| 614 | 625 | order to switch your lone working directory to the stable branch. |
| 615 | 626 | |
| 616 | 627 | Disk space is cheap. Having several working directories, each with its |
| 617 | 628 | own local state, makes switching versions cheap and fast. Plus, |
| 618 | -<tt>cd</tt> is faster to type than <tt>git checkout</tt>. | |
| 629 | +<tt>cd</tt> is faster to type than <tt>git checkout</tt> or <tt>fossil | |
| 630 | +update</tt>. | |
| 619 | 631 | |
| 620 | 632 | |
| 621 | 633 | <h3 id="history">2.7 What you should have done vs. What you actually did</h3> |
| 622 | 634 | |
| 623 | 635 | Git puts a lot of emphasis on maintaining |
| 624 | 636 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -562,21 +562,29 @@ | |
| 562 | tightly focused and cohesive implementation. |
| 563 | |
| 564 | |
| 565 | <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> |
| 566 | |
| 567 | The default mode of operation in Git is to have a single working |
| 568 | directory with a single <tt>.git</tt> subdirectory holding the actual |
| 569 | local repository contents. |
| 570 | |
| 571 | Fossil doesn't work that way. A Fossil repository is a SQLite database |
| 572 | file which is normally stored outside the working directory. You can |
| 573 | [/help?cmd=open | open] a Fossil repository any number of times into |
| 574 | any number of working directories. A common usage pattern is to have one |
| 575 | working directory per active working branch, so that switching branches |
| 576 | is done with a <tt>cd</tt> command rather than by checking out the |
| 577 | branches successively in a single working directory. |
| 578 | |
| 579 | You can use Git in the Fossil style, either by manually symlinking the |
| 580 | <tt>.git</tt> directory from one working directory to another or by use |
| 581 | of the <tt>[https://git-scm.com/docs/git-worktree|git-worktree]</tt> |
| 582 | feature. Nevertheless, Git's default tie between working directory and |
| @@ -583,41 +591,45 @@ | |
| 583 | repository means the standard method for working with a Git repo is to |
| 584 | have one working directory only. Most Git tutorials teach this style, so |
| 585 | it is how most people learn to use Git. Because relatively few people |
| 586 | use Git with multiple working directories per repository, there are |
| 587 | [https://duckduckgo.com/?q=git+worktree+problem | several known |
| 588 | problems] in working that way, which don't happen in Fossil because of |
| 589 | the clear separation between repository and working directory. |
| 590 | |
| 591 | Switching branches inside a single working directory loses local context |
| 592 | on each switch. |
| 593 | |
| 594 | For instance, in any software project where the runnable program must be |
| 595 | built from source files, you invalidate build objects on each switch, |
| 596 | artificially increasing the time required to switch versions. This |
| 597 | affects software written in statically-compiled programming languages |
| 598 | such as C, Java, and Haskell, but it can even affect programs written in |
| 599 | dynamic languages like JavaScript. A common |
| 600 | [https://en.wikipedia.org/wiki/Single-page_application | SPA] build |
| 601 | process involves a [http://browserify.org/ | Browserify] pass to convert |
| 602 | [https://nodejs.org/ | Node] packages to run in a web browser, |
| 603 | [https://sass-lang.com | SASS files] to CSS, |
| 604 | [https://www.typescriptlang.org | Typescript] to JavaScript, etc., to |
| 605 | say nothing of [https://github.com/mishoo/UglifyJS | uglification] and |
| 606 | other passes. Once all that processing work is done for a given input |
| 607 | file in a given working directory, why re-do that work just to switch |
| 608 | versions? |
| 609 | |
| 610 | For another example, you might have an active long-running test grinding |
| 611 | away in a working directory, then get a call from a customer requiring |
| 612 | that you switch to a stable branch to answer questions in terms of the |
| 613 | version that customer is running. You don't want to stop the test in |
| 614 | order to switch your lone working directory to the stable branch. |
| 615 | |
| 616 | Disk space is cheap. Having several working directories, each with its |
| 617 | own local state, makes switching versions cheap and fast. Plus, |
| 618 | <tt>cd</tt> is faster to type than <tt>git checkout</tt>. |
| 619 | |
| 620 | |
| 621 | <h3 id="history">2.7 What you should have done vs. What you actually did</h3> |
| 622 | |
| 623 | Git puts a lot of emphasis on maintaining |
| 624 |
| --- www/fossil-v-git.wiki | |
| +++ www/fossil-v-git.wiki | |
| @@ -562,21 +562,29 @@ | |
| 562 | tightly focused and cohesive implementation. |
| 563 | |
| 564 | |
| 565 | <h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3> |
| 566 | |
| 567 | Because Git commingles the repository data with the initial checkout of |
| 568 | that repository, the default mode of operation in Git is to stick to that |
| 569 | single work/repo tree, even when that's a shortsighted way of working. |
| 570 | |
| 571 | Fossil doesn't work that way. A Fossil repository is a SQLite database |
| 572 | file which is normally stored outside the working checkout directory. You can |
| 573 | [/help?cmd=open | open] a Fossil repository any number of times into |
| 574 | any number of working directories. A common usage pattern is to have one |
| 575 | working directory per active working branch, so that switching branches |
| 576 | is done with a <tt>cd</tt> command rather than by checking out the |
| 577 | branches successively in a single working directory. |
| 578 | |
| 579 | Fossil does allow you to switch branches within a working checkout |
| 580 | directory, and this is also often done. It is simply that there is no |
| 581 | inherent penalty to either choice in Fossil as there is in Git. The |
| 582 | standard advice is to use a switch-in-place workflow in Fossil when |
| 583 | the disturbance from switching branches is small, and to use multiple |
| 584 | checkouts when you have long-lived working branches that are different |
| 585 | enough that switching in place is disruptive. |
| 586 | |
| 587 | You can use Git in the Fossil style, either by manually symlinking the |
| 588 | <tt>.git</tt> directory from one working directory to another or by use |
| 589 | of the <tt>[https://git-scm.com/docs/git-worktree|git-worktree]</tt> |
| 590 | feature. Nevertheless, Git's default tie between working directory and |
| @@ -583,41 +591,45 @@ | |
| 591 | repository means the standard method for working with a Git repo is to |
| 592 | have one working directory only. Most Git tutorials teach this style, so |
| 593 | it is how most people learn to use Git. Because relatively few people |
| 594 | use Git with multiple working directories per repository, there are |
| 595 | [https://duckduckgo.com/?q=git+worktree+problem | several known |
| 596 | problems] with that way of working, problems which don't happen in Fossil because of |
| 597 | the clear separation between repository and working directory. |
| 598 | |
| 599 | This distinction matters because switching branches inside a single working directory loses local context |
| 600 | on each switch. |
| 601 | |
| 602 | For instance, in any software project where the runnable program must be |
| 603 | built from source files, you invalidate build objects on each switch, |
| 604 | artificially increasing the time required to switch versions. Most obviously, this |
| 605 | affects software written in statically-compiled programming languages |
| 606 | such as C, Java, and Haskell, but it can even affect programs written in |
| 607 | dynamic languages like JavaScript. A typical |
| 608 | [https://en.wikipedia.org/wiki/Single-page_application | SPA] build |
| 609 | process involves several passes: [http://browserify.org/ | Browserify] to convert |
| 610 | [https://nodejs.org/ | Node] packages so they'll run in a web browser, |
| 611 | [https://sass-lang.com | SASS] to CSS translation, |
| 612 | transpilation of [https://www.typescriptlang.org | Typescript] to JavaScript, |
| 613 | [https://github.com/mishoo/UglifyJS | uglification], etc. |
| 614 | Once all that processing work is done for a given input |
| 615 | file in a given working directory, why re-do that work just to switch |
| 616 | versions? If most of the files that differ between versions don't change |
| 617 | very often, you can save substantial time by switching branches with |
| 618 | <tt>cd</tt> rather than swapping versions in-place within a working |
| 619 | checkout directory. |
| 620 | |
| 621 | For another example, you might have an active long-running test grinding |
| 622 | away in a working directory, then get a call from a customer requiring |
| 623 | that you switch to a stable branch to answer questions in terms of the |
| 624 | version that customer is running. You don't want to stop the test in |
| 625 | order to switch your lone working directory to the stable branch. |
| 626 | |
| 627 | Disk space is cheap. Having several working directories, each with its |
| 628 | own local state, makes switching versions cheap and fast. Plus, |
| 629 | <tt>cd</tt> is faster to type than <tt>git checkout</tt> or <tt>fossil |
| 630 | update</tt>. |
| 631 | |
| 632 | |
| 633 | <h3 id="history">2.7 What you should have done vs. What you actually did</h3> |
| 634 | |
| 635 | Git puts a lot of emphasis on maintaining |
| 636 |