Fossil

Check-in [f6e04cc4]
Login

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

Overview
Comment: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
Downloads: Tarball | ZIP archive | SQL archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA3-256: f6e04cc4233629b59a5ded9dd488d7e45d247cde75828efc87bbc37c17712fe9
User & Date: wyoung 2020-01-08 18:05:39
Original Comment: 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
Context
2020-01-08
18:28
Added "more" column to the fossil-v-git doc: we have evidence of people reading only the summary table at the top and then reacting to their understanding of that brief one-line characaterization of the difference rather than engaging with the detailed arguments making up the bulk of the article. check-in: fd9e211d user: wyoung tags: trunk
18:05
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 check-in: f6e04cc4 user: wyoung tags: trunk
2020-01-02
14:35
Fix the spelling of "legacy" in the "test-fingerprint" command. Also show the current Fossil version in the "test-fingerprint" command. check-in: 2af7fedd user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to www/fossil-v-git.wiki.

560
561
562
563
564
565
566

567
568
569
570
571
572
573
574
575
576
577








578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608



609
610
611
612
613
614
615
616
617
618

619
620
621
622
623
624
625
changes on all branches all at once helps keep the whole team
up-to-date with what everybody else is doing, resulting in a more 
tightly focused and cohesive implementation.


<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>


The default mode of operation in Git is to have a single working
directory with a single <tt>.git</tt> subdirectory holding the actual
local repository contents.

Fossil doesn't work that way. A Fossil repository is a SQLite database
file which is normally stored outside the working directory. You can
[/help?cmd=open | open] a Fossil repository any number of times into
any number of working directories. A common usage pattern is to have one
working directory per active working branch, so that switching branches
is done with a <tt>cd</tt> command rather than by checking out the
branches successively in a single working directory.









You can use Git in the Fossil style, either by manually symlinking the
<tt>.git</tt> directory from one working directory to another or by use
of the <tt>[https://git-scm.com/docs/git-worktree|git-worktree]</tt>
feature. Nevertheless, Git's default tie between working directory and
repository means the standard method for working with a Git repo is to
have one working directory only. Most Git tutorials teach this style, so
it is how most people learn to use Git. Because relatively few people
use Git with multiple working directories per repository, there are
[https://duckduckgo.com/?q=git+worktree+problem | several known
problems] in working that way, which don't happen in Fossil because of
the clear separation between repository and working directory.

Switching branches inside a single working directory loses local context
on each switch.

For instance, in any software project where the runnable program must be
built from source files, you invalidate build objects on each switch,
artificially increasing the time required to switch versions. This
affects software written in statically-compiled programming languages
such as C, Java, and Haskell, but it can even affect programs written in
dynamic languages like JavaScript. A common
[https://en.wikipedia.org/wiki/Single-page_application | SPA] build
process involves a [http://browserify.org/ | Browserify] pass to convert
[https://nodejs.org/ | Node] packages to run in a web browser,
[https://sass-lang.com | SASS files] to CSS,
[https://www.typescriptlang.org | Typescript] to JavaScript, etc., to
say nothing of [https://github.com/mishoo/UglifyJS | uglification] and
other passes. Once all that processing work is done for a given input
file in a given working directory, why re-do that work just to switch
versions?




For another example, you might have an active long-running test grinding
away in a working directory, then get a call from a customer requiring
that you switch to a stable branch to answer questions in terms of the
version that customer is running. You don't want to stop the test in
order to switch your lone working directory to the stable branch.

Disk space is cheap. Having several working directories, each with its
own local state, makes switching versions cheap and fast. Plus,
<tt>cd</tt> is faster to type than <tt>git checkout</tt>.



<h3 id="history">2.7 What you should have done vs. What you actually did</h3>

Git puts a lot of emphasis on maintaining
a "clean" check-in history.  Extraneous and experimental branches by
individual developers often never make it into the main repository.  And







>
|
<
|


|





>
>
>
>
>
>
>
>










|


|




|


|

|
|
|
|
|
|

|
>
>
>









|
>







560
561
562
563
564
565
566
567
568

569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
changes on all branches all at once helps keep the whole team
up-to-date with what everybody else is doing, resulting in a more 
tightly focused and cohesive implementation.


<h3 id="checkouts">2.6 One vs. Many Check-outs per Repository</h3>

Because Git commingles the repository data with the initial checkout of
that repository, the default mode of operation in Git is to stick to that

single work/repo tree, even when that's a shortsighted way of working.

Fossil doesn't work that way. A Fossil repository is a SQLite database
file which is normally stored outside the working checkout directory. You can
[/help?cmd=open | open] a Fossil repository any number of times into
any number of working directories. A common usage pattern is to have one
working directory per active working branch, so that switching branches
is done with a <tt>cd</tt> command rather than by checking out the
branches successively in a single working directory.

Fossil does allow you to switch branches within a working checkout
directory, and this is also often done. It is simply that there is no
inherent penalty to either choice in Fossil as there is in Git. The
standard advice is to use a switch-in-place workflow in Fossil when
the disturbance from switching branches is small, and to use multiple
checkouts when you have long-lived working branches that are different
enough that switching in place is disruptive.

You can use Git in the Fossil style, either by manually symlinking the
<tt>.git</tt> directory from one working directory to another or by use
of the <tt>[https://git-scm.com/docs/git-worktree|git-worktree]</tt>
feature. Nevertheless, Git's default tie between working directory and
repository means the standard method for working with a Git repo is to
have one working directory only. Most Git tutorials teach this style, so
it is how most people learn to use Git. Because relatively few people
use Git with multiple working directories per repository, there are
[https://duckduckgo.com/?q=git+worktree+problem | several known
problems] with that way of working, problems which don't happen in Fossil because of
the clear separation between repository and working directory.

This distinction matters because switching branches inside a single working directory loses local context
on each switch.

For instance, in any software project where the runnable program must be
built from source files, you invalidate build objects on each switch,
artificially increasing the time required to switch versions. Most obviously, this
affects software written in statically-compiled programming languages
such as C, Java, and Haskell, but it can even affect programs written in
dynamic languages like JavaScript. A typical
[https://en.wikipedia.org/wiki/Single-page_application | SPA] build
process involves several passes: [http://browserify.org/ | Browserify] to convert
[https://nodejs.org/ | Node] packages so they'll run in a web browser,
[https://sass-lang.com | SASS] to CSS translation,
transpilation of [https://www.typescriptlang.org | Typescript] to JavaScript,
[https://github.com/mishoo/UglifyJS | uglification], etc.
Once all that processing work is done for a given input
file in a given working directory, why re-do that work just to switch
versions? If most of the files that differ between versions don't change
very often, you can save substantial time by switching branches with
<tt>cd</tt> rather than swapping versions in-place within a working
checkout directory.

For another example, you might have an active long-running test grinding
away in a working directory, then get a call from a customer requiring
that you switch to a stable branch to answer questions in terms of the
version that customer is running. You don't want to stop the test in
order to switch your lone working directory to the stable branch.

Disk space is cheap. Having several working directories, each with its
own local state, makes switching versions cheap and fast. Plus,
<tt>cd</tt> is faster to type than <tt>git checkout</tt> or <tt>fossil
update</tt>.


<h3 id="history">2.7 What you should have done vs. What you actually did</h3>

Git puts a lot of emphasis on maintaining
a "clean" check-in history.  Extraneous and experimental branches by
individual developers often never make it into the main repository.  And