26 ms·

I've been using fossil (https://fossil-scm.org https://fossil-scm.org) for personal projects for like a decade now and I much prefer it over git. The characteri

by sriku 4y ago

I've been using fossil (https://fossil-scm.org https://fossil-scm.org) for personal projects for like a decade now and I much prefer it over git. The characteristics that get me to stick with it are - 1. Single file executable. No dependencies to "install". Just the executable and you're good. 2. The whole repo is a single sqlite DB file. Fabulous for backups, sharing, hosting etc. 3. You cannot rewrite history unlike git. Hence the name. Folks using git have no idea what kind of a peace of mind this gives me. 4. Integrated issue tracker stored in the same repo. Complete with cross references to commits. 5. Allows repeated use of same tag name. This is so convenient in personal projects I miss it in git. You can mark a commit as "published" and later look at the whole history of all previous commits tagged as "published". Other niceties - 1. Integrated wiki - I've occasionally used it, but usually prefer to write documentation in separate files. 2. Integrated webserver - `fossil ui` runs on the same thing so I do use it. The webserver comes complete with user account management and permissioning. 3. Can export and import to/from git.

geenat 4y ago
How is large file support? What strategy is employed for binary file handling? How does it compare to git LFS / annex / mercurial? Aside from that, Fossil is very intriguing.
- sgbeal 4y ago
  > How is large file support? Fossil is, because of its sqlite dependency, limited to blobs no larger than 2GB each. Some of its algorithms require keeping two versions of a file in memory at once, so "stupidly huge" blobs are not something it's ideal for. Fossil is designed for SCM'ing source code, and source code never gets anywhere near 2GB per file. The only projects which use such files seem to be (based on fossil forum traffic) high-end games and similar media-heavy/media-centric projects which fossil is not designed for. > What strategy is employed for binary file handling? That's a vague question, so here's a vague answer: it handles binaries just fine and can delta them just fine. It cannot do automatic merging of binary files which have been edited concurrently by 2+ users because doing so requires file-format-specific logic. (AFAIK _no_ SCM can merge (as opposed to delta) binaries of any sort.)
  - geenat 4y ago
    Fair enough, like vanilla git as of today. I do hope someday git and others employ either a git annex or mercurial-style scheme where if it's a large binary file: 1. no diff is performed, and 2. only the latest version is kept within the history. This would blow wide open the possibilities for using Fossil in binary-heavy projects such as machine learning, games, simulation. I could see the SQLite limitation worked around by just splitting up binary data into multiple pieces.
    - sgbeal 4y ago
      > I do hope someday git and others employ either a git annex or mercurial-style scheme where if it's a large binary file: 1. no diff is performed, and 2. only the latest version is kept within the history. That will never happen in fossil: one of fossil's core-most design features and goals is that it remembers _everything_, not just the latest copy of a file. The way it records checkins, as a list of files and their hashes, is fundamentally incompatible with the notion of tossing out files. It is capable of permanently removing content, but that's a feature best reserved for removal of content which should never have been checked in (e.g. passwords, legally problematic checkins, etc.). Removing content from a fossil repo punches holes in the DAG/blockchain and is always to be considered a measure of last resort. In my 14+ years in the fossil community, i can count on 2 fingers the number of times i've recommended that a user use that capability. > I could see the SQLite limitation worked around by just splitting up binary data into multiple pieces. There's no need to work around that "limitation" because "source code" trees don't deal with files of anywhere _near_ that size. Fossil is, first and foremost, designed to support the sqlite project itself: it was literally designed and written to be sqlite's SCM. Projects with scales of 1000x that project's are nowhere near fossil's radar. Sharding large files over multiple blobs doesn't solve some of the underlying limitations, e.g. performing deltas. Fossil's delta algorithm requires that both the "v1" and "v2" versions of a given piece of content be in memory at once (along with the delta itself), and rewriting it to account for sharded blobs would be an undertaking in and of itself. That's almost certain to never happen until/unless the sqlite project needs such a feature (which, i'm confident in saying, it never will). TL;DR: fossil is, plain and simple, not the SCM for projects which need massive blobs.
L3viathan 4y ago
1: What does it matter? I do $packagemanager install git and am done. What do I care whether it's got dependencies or consists of several binaries? 2: Fair enough. Although a multi-file backup doesn't sound hard to me either. 3: That would give me the opposite of peace of mind. I can't clean up my messy WIP commits? 4: Sounds like a nice feature. 5: This just uses the term "tag" to mean something else that git tags. But I agree that it would be nice to be able to label several commits (distinct from tags).
- sgbeal 4y ago
  > What does it matter? I do $packagemanager install git and am done. _Freedom_. Fossil is trivial to build on all modern platforms and we (in the fossil project) always recommend that folks use the trunk version, building it for themselves. Depending on an OS'es package manager just means that one is stuck with whatever version that package repo's volunteer package maintainers post. > I can't clean up my messy WIP commits? Nope. Fossil remembers what happened, not what "should have" happened. We (on the fossil project) consider that a feature, and fossil's own history is littered with "oopsies" (no small percentage of them from yours truly).
  - colejohnson66 4y ago
    I'm torn on that "feature." On one hand, I think it's a neat idea, but on the other, I amend commits in Git quite often before pushing. It would take a mindset change to switch. And then there's this: what if I accidentally commit a private key or database? Sure, I shouldn't be f-ing up, but we all know it happens sometimes. In Git, I can revert/reset back to the commit prior.
    - sgbeal 4y ago
      > I amend commits in Git quite often before pushing. Fossil supports amending checkins at any time after committing, as often as you like - change the checkin commit, re-attribute to a different user, change the timestamp, or similar. What it doesn't support is _modifying_ them. > And then there's this: what if I accidentally commit a private key or database? Then you "shun" (to use fossil's term) that artifact. Fossil isn't 100% merciless when it comes to removing content, it just makes doing so a 4th-class sub-citizen of a feature and recommends against doing so in every case except for the one of content which should never have been checked in. Removing content inherently punches holes in the project history, so it's not something we (in the fossil project) recommend doing unless it's absolutely necessary for reasons of security or legality.
sgbeal 4y ago
(A long-time fossil dev here...) Re. integrated wiki: when i first saw fossil (Christmas break of 2007) two features made it a killer app for me: wiki and hosting as a CGI. The wiki aspect has long since taken a back seat to the so-called "embedded docs" feature, where the docs live in the source tree and become first-class SCM citizens. However fossil is, to the best of my knowledge, still the only SCM which is absolutely trivial to host as a CGI, which means it can be hosted on cheap shared hosters just as easily as it can on one's standalone VPS. As far as "what comes after git," though: git is the SCM needed by the 0.1% (or fewer) of the largest, most-active FOSS projects. Imagine the Linux kernel source tree if its SCM could not remove dead branches - it would quickly become uncloneable under all of that weight. Fossil is not designed to scale to projects of that size. Fossil is, however, an ideal SCM for that 98%+ of remaining projects which fall into the size categories of personal/small/medium.
- open-source-ux 4y ago
  "Fossil is, however, an ideal SCM for that 98%+ of remaining projects which fall into the size categories of personal/small/medium." I wonder why so few developers consider the scenario you describe. Git fits the development of Linux. But, a question rarely raised: why is Git considered suitable for small or medium projects?
  - sgbeal 4y ago
    > A question rarely raised: why is Git considered suitable for small or medium projects? Quite frankly, _it's not_. There's _absolutely nothing_ ideal about git except for its ability to super-scale to that _exceedingly small_ percentage of projects which need that level of scaling. That's its _one and only_ killer feature. If it weren't for github and its ilk, git would be just another second-tier tool like the rest of the SCMs. Unlike every(?) other SCM, fossil doesn't require 3rd-party tools to host over CGI: that's built right in to it and CGI works on even the cheapest of shared-hosting platforms, so no equivalent of github is required in order to host one's own repositories. Granted, as a long-time fossil dev and advocate, i'm _severely_ biased in this regard, but there's are _reasons_ i prefer fossil over git, why i use it for _all_ of my own projects (fossil.wanderinghorse.net), and why i support and advocate for it (just not for that small tier of "uncommonly large" projects, as fossil has, quite frankly, no business being used there).
al2o3cr 4y ago
3. You cannot rewrite history unlike git. Hence the name. So if somebody accidentally commits customer data to the monorepo, just burn down the whole company and start over?
- leethargo 4y ago
  I'm guessing you can still go back in time and just "forget" what came after wards, by using backups of the repo file.
- sgbeal 4y ago
  > So if somebody accidentally commits customer data to the monorepo First, you use that as a "teaching opportunity" to educate that someone about why doing so is Bad for Business. Secondly, you "shun" the artifact(s) in question. Since shunning burns holes in the project history (DAG and blockchain), we (in the fossil project) invariably advise against going so unless it's absolutely necessary (publishing custom data being an example of "necessary"). There's a major semantic difference between deleting content "just to cleanup the history" vs. "to eliminate legal liability." > , just burn down the whole company and start over? If you prefer that approach then have at it.

by sriku 4y ago

geenat 4y ago

How is large file support? What strategy is employed for binary file handling? How does it compare to git LFS / annex / mercurial? Aside from that, Fossil is very intriguing.

sgbeal 4y ago
> How is large file support? Fossil is, because of its sqlite dependency, limited to blobs no larger than 2GB each. Some of its algorithms require keeping two versions of a file in memory at once, so "stupidly huge" blobs are not something it's ideal for. Fossil is designed for SCM'ing source code, and source code never gets anywhere near 2GB per file. The only projects which use such files seem to be (based on fossil forum traffic) high-end games and similar media-heavy/media-centric projects which fossil is not designed for. > What strategy is employed for binary file handling? That's a vague question, so here's a vague answer: it handles binaries just fine and can delta them just fine. It cannot do automatic merging of binary files which have been edited concurrently by 2+ users because doing so requires file-format-specific logic. (AFAIK _no_ SCM can merge (as opposed to delta) binaries of any sort.)
- geenat 4y ago
  Fair enough, like vanilla git as of today. I do hope someday git and others employ either a git annex or mercurial-style scheme where if it's a large binary file: 1. no diff is performed, and 2. only the latest version is kept within the history. This would blow wide open the possibilities for using Fossil in binary-heavy projects such as machine learning, games, simulation. I could see the SQLite limitation worked around by just splitting up binary data into multiple pieces.
  - sgbeal 4y ago
    > I do hope someday git and others employ either a git annex or mercurial-style scheme where if it's a large binary file: 1. no diff is performed, and 2. only the latest version is kept within the history. That will never happen in fossil: one of fossil's core-most design features and goals is that it remembers _everything_, not just the latest copy of a file. The way it records checkins, as a list of files and their hashes, is fundamentally incompatible with the notion of tossing out files. It is capable of permanently removing content, but that's a feature best reserved for removal of content which should never have been checked in (e.g. passwords, legally problematic checkins, etc.). Removing content from a fossil repo punches holes in the DAG/blockchain and is always to be considered a measure of last resort. In my 14+ years in the fossil community, i can count on 2 fingers the number of times i've recommended that a user use that capability. > I could see the SQLite limitation worked around by just splitting up binary data into multiple pieces. There's no need to work around that "limitation" because "source code" trees don't deal with files of anywhere _near_ that size. Fossil is, first and foremost, designed to support the sqlite project itself: it was literally designed and written to be sqlite's SCM. Projects with scales of 1000x that project's are nowhere near fossil's radar. Sharding large files over multiple blobs doesn't solve some of the underlying limitations, e.g. performing deltas. Fossil's delta algorithm requires that both the "v1" and "v2" versions of a given piece of content be in memory at once (along with the delta itself), and rewriting it to account for sharded blobs would be an undertaking in and of itself. That's almost certain to never happen until/unless the sqlite project needs such a feature (which, i'm confident in saying, it never will). TL;DR: fossil is, plain and simple, not the SCM for projects which need massive blobs.

L3viathan 4y ago

1: What does it matter? I do $packagemanager install git and am done. What do I care whether it's got dependencies or consists of several binaries? 2: Fair enough. Although a multi-file backup doesn't sound hard to me either. 3: That would give me the opposite of peace of mind. I can't clean up my messy WIP commits? 4: Sounds like a nice feature. 5: This just uses the term "tag" to mean something else that git tags. But I agree that it would be nice to be able to label several commits (distinct from tags).

sgbeal 4y ago
> What does it matter? I do $packagemanager install git and am done. _Freedom_. Fossil is trivial to build on all modern platforms and we (in the fossil project) always recommend that folks use the trunk version, building it for themselves. Depending on an OS'es package manager just means that one is stuck with whatever version that package repo's volunteer package maintainers post. > I can't clean up my messy WIP commits? Nope. Fossil remembers what happened, not what "should have" happened. We (on the fossil project) consider that a feature, and fossil's own history is littered with "oopsies" (no small percentage of them from yours truly).
- colejohnson66 4y ago
  I'm torn on that "feature." On one hand, I think it's a neat idea, but on the other, I amend commits in Git quite often before pushing. It would take a mindset change to switch. And then there's this: what if I accidentally commit a private key or database? Sure, I shouldn't be f-ing up, but we all know it happens sometimes. In Git, I can revert/reset back to the commit prior.
  - sgbeal 4y ago
    > I amend commits in Git quite often before pushing. Fossil supports amending checkins at any time after committing, as often as you like - change the checkin commit, re-attribute to a different user, change the timestamp, or similar. What it doesn't support is _modifying_ them. > And then there's this: what if I accidentally commit a private key or database? Then you "shun" (to use fossil's term) that artifact. Fossil isn't 100% merciless when it comes to removing content, it just makes doing so a 4th-class sub-citizen of a feature and recommends against doing so in every case except for the one of content which should never have been checked in. Removing content inherently punches holes in the project history, so it's not something we (in the fossil project) recommend doing unless it's absolutely necessary for reasons of security or legality.

sgbeal 4y ago

(A long-time fossil dev here...) Re. integrated wiki: when i first saw fossil (Christmas break of 2007) two features made it a killer app for me: wiki and hosting as a CGI. The wiki aspect has long since taken a back seat to the so-called "embedded docs" feature, where the docs live in the source tree and become first-class SCM citizens. However fossil is, to the best of my knowledge, still the only SCM which is absolutely trivial to host as a CGI, which means it can be hosted on cheap shared hosters just as easily as it can on one's standalone VPS. As far as "what comes after git," though: git is the SCM needed by the 0.1% (or fewer) of the largest, most-active FOSS projects. Imagine the Linux kernel source tree if its SCM could not remove dead branches - it would quickly become uncloneable under all of that weight. Fossil is not designed to scale to projects of that size. Fossil is, however, an ideal SCM for that 98%+ of remaining projects which fall into the size categories of personal/small/medium.

open-source-ux 4y ago
"Fossil is, however, an ideal SCM for that 98%+ of remaining projects which fall into the size categories of personal/small/medium." I wonder why so few developers consider the scenario you describe. Git fits the development of Linux. But, a question rarely raised: why is Git considered suitable for small or medium projects?
- sgbeal 4y ago
  > A question rarely raised: why is Git considered suitable for small or medium projects? Quite frankly, _it's not_. There's _absolutely nothing_ ideal about git except for its ability to super-scale to that _exceedingly small_ percentage of projects which need that level of scaling. That's its _one and only_ killer feature. If it weren't for github and its ilk, git would be just another second-tier tool like the rest of the SCMs. Unlike every(?) other SCM, fossil doesn't require 3rd-party tools to host over CGI: that's built right in to it and CGI works on even the cheapest of shared-hosting platforms, so no equivalent of github is required in order to host one's own repositories. Granted, as a long-time fossil dev and advocate, i'm _severely_ biased in this regard, but there's are _reasons_ i prefer fossil over git, why i use it for _all_ of my own projects (fossil.wanderinghorse.net), and why i support and advocate for it (just not for that small tier of "uncommonly large" projects, as fossil has, quite frankly, no business being used there).

al2o3cr 4y ago

3. You cannot rewrite history unlike git. Hence the name. So if somebody accidentally commits customer data to the monorepo, just burn down the whole company and start over?

leethargo 4y ago
I'm guessing you can still go back in time and just "forget" what came after wards, by using backups of the repo file.
sgbeal 4y ago
> So if somebody accidentally commits customer data to the monorepo First, you use that as a "teaching opportunity" to educate that someone about why doing so is Bad for Business. Secondly, you "shun" the artifact(s) in question. Since shunning burns holes in the project history (DAG and blockchain), we (in the fossil project) invariably advise against going so unless it's absolutely necessary (publishing custom data being an example of "necessary"). There's a major semantic difference between deleting content "just to cleanup the history" vs. "to eliminate legal liability." > , just burn down the whole company and start over? If you prefer that approach then have at it.