9 ms·

Does anyone use Fossil? I'm considering it for my personal projects. I like all it offers for the relatively low resource usage. The only use of it I've seen i

Does anyone use Fossil? I'm considering it for my personal projects. I like all it offers for the relatively low resource usage. The only use of it I've seen in the wild is Ripcord (https://dev.cancel.fm/issues https://dev.cancel.fm/issues), which is interestingly also relatively low resource usage compared to its competitor.

arsome 6y ago
SQLite is probably the best known user of it https://sqlite.org/src/doc/trunk/README.md https://sqlite.org/src/doc/trunk/README.md https://www.sqlite.org/whynotgit.html https://www.sqlite.org/whynotgit.html
Tomte 6y ago
SQLite obviously. Probably some other projects in the Tcl and SQLite world.
sigzero 6y ago
The TCT (Tcl Core Team) uses it heavily. They seem to like it a lot.
- exikyut 6y ago
  Ah, due to (who would've thunk) the SQLite connection.
  - sigzero 6y ago
    That probably had a lot to do with it I am sure.
    - bch 6y ago
      > Ah, due to (who would've thunk) the SQLite connection. The “SQLite connection” is manifold - indeed drh (SQLite author) used to be on the Tcl Core Team, and is an unapologetic user of Tcl. SQLite itself isn’t just “well-supported” in Tcl, it started there. drh calls SQLite “a tcl extension that escaped into the wild”, among other things, and that “...SQLite is still heavily dependent upon TCL and the ongoing support, maintenance, and enhancement of SQLite would not be possible without TCL, and would be seriously inconvenienced without Tk.” [0][1] The ties are interesting and deep. [0] https://sqlite.org/tclsqlite.html https://sqlite.org/tclsqlite.html [1] https://www.tcl.tk/community/tcl2017/assets/talk93/Paper.html https://www.tcl.tk/community/tcl2017/assets/talk93/Paper.htm...
      - sgbeal 6y ago
        > The ties are interesting and deep. Brad! You're alive! In case you hadn't heard: libfossil was recently revived, has been brought up to date with regards to SHA3 hashes, and got both "update" and "revert" APIs within the past week or two. The "last" major day-to-day feature it's missing is merge. We have the merge algo (it's used by update), but not yet the equivalent of the merge command. Your account is still active on the repo (https://fossil.wanderinghorse.net/r/libfossil https://fossil.wanderinghorse.net/r/libfossil).
        bch 6y ago
        I’ll ping you offline. I’d love to get back to that with you. Also enjoy seeing your comments all over this article :)
KwanEsq 6y ago
SQLite famously does so: https://www.sqlite.org/cgi/src https://www.sqlite.org/cgi/src
mgreenleaf 6y ago
I use it for most of my projects, with git covering the rest of them. I prefer the cli usage, philosophy, single binary / single file repository, and having all the notes/issues transfer across when I push makes it easier to develop and test across windows/linux/bsd. Autosync and other things are well-thought out details too; generally feels well designed. Otherwise, day to day usage isn't much different.
emodendroket 6y ago
It seems to me like you’d want it to be obviously way superior for some reason to go so far away from the herd.
- mscrnt 6y ago
  You’d forsake an improvement for the sake of following the rest of the cattle? Have you used it, yet, to see if it sufficiently meets your way superior standard to break free from the herd?
  - emodendroket 6y ago
    Well yeah because git is, I find, good enough that I don’t have much desire to experiment with other SCM tools. Some people love customizing every part of their tool chain but to me it’s better to stick with something familiar with things like that so I can focus on solving my actual problem.
    - mscrnt 6y ago
      But have you tried Fossil to see if it does meet your way superior standard? Unless you're working on Linux kernel- or BSD-sized repositories, Fossil is arguably a better fit than Git. You don't need to customise anything out of the box—it's literally a single binary anywhere on your path and you have your version control, bug tracking, wiki, forum, chat, technotes, etc. in-house. Your team won't need to visit but one server—that really streamlines focusing on solving your actual problem.
      - emodendroket 6y ago
        Pretty much everyone already uses git and some kind of issue tracker so the question is more if it's so much better to justify learning a new thing, not if it is slightly better in the abstract. It is not immediately obvious to me that bundling all these things into one tool is going to give better results, especially when you have non-developer users in the mix.
Hendrikto 6y ago
Fossil looks very interesting, but I completely disagree with their [stance on rebasing](https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md). This is a dealbreaker for me. I do not consider having 10 buggy commits per feature instead of 1 working one an advantage. It just complicates reading history and hinders debugging (e.g. bisect). I get their arguments, I just disagree.
- rubyist5eva 6y ago
  This is what private branches are for - when you merge them and sync they show up as a single commit on the mainline branch - not too different from git merge --squash.
  - mscrnt 6y ago
    That, and it's very easy to hide commits from the timeline too. You can get most if not all the benefits of rebase without losing history—that's a good thing.
  - deleted 6y ago
    [deleted]
- iudqnolq 6y ago
  The theory is that you don't see those 10 commits unless you choose to. I think they're right in theory that a Sufficiently Smart^TM scm should be able to work better by not throwing data away, but I haven't tested if it actually works in practice. > The Git documentation acknowledges this fact (in so many words) and justifies it by saying "rebasing makes for a cleaner history." I read that sentence as a tacit admission that the Git history display capabilities are weak and need active assistance from the user to keep things manageable. Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying, but retain the option to show the real, complete, messy history for cases where detail and accuracy are more important.
- dahart 6y ago
theamk 6y ago
I avoid it because of complete lack of commit amendment tools. It seems like quarter of the time I make a commit I mess up either a commit message or a file list, and have to "git amend". I have no idea how the sqlite devs live without the feature, they must be much more careful programmers than I am.
- mscrnt 6y ago
  You could always try "fossil amend" as a commit amendment tool for starters.
- rkeene2 6y ago
  There has pretty much always been a way to amend commits -- the difference is in Fossil this amendment is done by writing a new journal entry (artifact) noting which commit is being amended and how, rather than modifying the commit directly. Generally, the compiled version (base+resultant set of amendments) is displayed to the user, but the entries which modified the commit are also available to be seen.
  - everybodyknows 6y ago
    >modifying the commit directly. Git preserves a record of the origial commit, plus amendments leading up to the final - git-reflog. The reflog is however subject to periodic pruning by default - see git-gc.
    - rkeene2 6y ago
      Fossil preserves the journal of activities forever, and across clones.
- sgbeal 6y ago
  > I avoid it because of complete lack of commit amendment tools. That's downright wrong: https://fossil-scm.org/home/help/amend https://fossil-scm.org/home/help/amend
rcarmo 6y ago
I used it for quite some time, still have archived repos on it because they’re a single file and very easy to move around. Mostly moved to gitea on a home NAS for the GitHub sync capability (makes it easy to have a local copy of dependencies, etc.) But I do miss the straightforwardness (and sometimes bluntness) of fossil sometimes. Much easier to deal with for personal projects.
chillfox 6y ago
I use it for any personal projects that are large enough that I want a few pages of documentation and a ticket system to keep track of planned features. The ticket system can be configured quite a bit, so I usually set it up like a todo list with: “to do, doing, done”.
rkeene2 6y ago
I use Fossil and run a Fossil hosting service called ChiselApp [0]. I've used Fossil for all kinds of projects big (commercial Linux distributions, with installer ISO as the result of the CI/CD pipeline stored as Fossil Unversioned content artifacts) to small (a single file demo), but primarily with only a small number of developers. [0] https://chiselapp.com/ https://chiselapp.com/
- AnonHP 6y ago
  Could you please put up a post on the ChiselApp website about your motivations for running a free service, how you manage it, etc.? It’s always interesting to see these free services without a commercial angle, and makes me wonder why they’re there, how they sustain themselves, what restrictions they impose on users, and related matters.
  - rkeene2 6y ago
    I run it because I use Fossil a lot and want a low-friction way to create new repos. It doesn't cost me anything to run since I already had extra CPU, RAM, and Disk capacity on my personal server.
petre 6y ago
Yes, we use it. It's awesome. Thank you again D. Richard Hipp.
silasdb 6y ago
I decided to give it a try on a new project and, although it seemed strange at first (coming from years using git), I fell in love with it and I'm converting all my own projects to fossil. It does everything other SCMs do. It also can do everything git does, but in a saner way. Also, the self-hosting capabilities in a few MB binary are astonishing and you just don't pay for what you don't use. In my own repositories, I don't use chat nor wiki pages, but I do use forum, the ticket system and technotes. The community and developers are very nice to answer questions too, and are open for suggestions. There is room for even further improvement and it is more a matter of someone showing up willing to develop the specific feature of the project.
sgbeal 6y ago
> Does anyone use Fossil? Almost literally every day since Christmas break of 2007. > I like all it offers for the relatively low resource usage. And setting it up to run over CGI (e.g. over a $5/month shared hoster) takes about 90 seconds and requires no additional apps. That was the initial Killer Feature for me, and is still critical for me. i host dozens of repositories over CGI on an inexpensive shared hoster (https://fossil.wanderinghorse.net https://fossil.wanderinghorse.net), and couldn't do that with any other SCM.
zzo38computer 6y ago
I use Fossil for my own projects. However, I do not use the forum feature, chat feature, etc. They don't belong there in my opinion, nor do I like the implementation much; I use external software. There are a few other things I dislike about the design of Fossil; it doesn't have very good low level access, for one thing (there are other concerns too, although rebase isn't one of them). I have started to make my own implementation, which I intend to support the Fossil protocol and deconstruction format. Someone else perhaps had a similar idea, so were writing libfossil; however, they seem to consider the protocol implementation a lower priority, while I consider it important (however, they consider it important to use the same database schema, while I don't, and can freely rewrite it). As it turns out, both of us had independently used the term "deck" or Fossil structural artifacts.
- sgbeal 6y ago
  > Someone else perhaps had a similar idea, so were writing libfossil; however, they seem to consider the protocol implementation a lower priority, That's me (https://fossil.wanderinghorse.net/r/libfossil https://fossil.wanderinghorse.net/r/libfossil). The protocol is irrelevant to the implementation of the underlying core algorithms and data format. The sync protocol is a completely separate layer which can be reimplemented any number of ways without affecting the underlying data model. Without the core data model and algos implemented, the sync protocol is useless because it has nothing to sync. Ergo: first implement the data model, then the sync. > (however, they consider it important to use the same database schema, while I don't, and can freely rewrite it) That's a really interesting topic, actually. The core data model is 100% independent of any given schema (or storage model, for that matter), so anyone implementing a compatible (at the data model level) tool is free to use whatever storage or schema they want. The fact is, though, that libfossil could never have gotten as far as it has without re-using much of what Richard has already designed, and that includes the schema and core SCM-relevant algorithms. As a long-time fossil contributor, it's important to me that the libfossil tools be as compatible as feasible with fossil, and that means using the same schema (for better or worse). That said: i would very much like to see the core data model implemented on top of another schema, just to see it done. Alas, i don't have the energy to create, from scratch, such a beast, nor to maintain it, so my path is one of lower resistance: re-use what's already been designed and which works well within the fossil project. i'd love to see what you have when you're ready to post it, though. (i recall you(?) posting about this in the fossil forum before - feel free to announce your project there when you're ready.) > As it turns out, both of us had independently used the term "deck" or Fossil structural artifacts. What else would one call a "container of cards"? :)
mscrnt 6y ago
> Does anyone use Fossil? Daily, across a half dozen odd repos, and it greatly simplified my life since switching from Git. My primary wish is to have the forum compatible with email. And the next would be a partial commit option akin to 'git commit -p' although I think this is missed more than it was ever used. At first, I thought the chat was an odd addition but it's being used daily on all repos, and has really improved team cohesion and productivity. The ability to view documentation changes in the browser while still in the local checkout but not yet committed has also proved quite valuable. Having the repository contained in one file is handy, and frequenting one server for all dev related work is a huge bonus. It's unbelievably easy to setup, and the command line syntax and help is highly intuitive and simple, making transition a breeze and continued use a joy. It's a great piece of software for any team working on your typically-sized repo.

arsome 6y ago

SQLite is probably the best known user of it https://sqlite.org/src/doc/trunk/README.md https://sqlite.org/src/doc/trunk/README.md https://www.sqlite.org/whynotgit.html https://www.sqlite.org/whynotgit.html

Tomte 6y ago

SQLite obviously. Probably some other projects in the Tcl and SQLite world.

sigzero 6y ago

The TCT (Tcl Core Team) uses it heavily. They seem to like it a lot.

exikyut 6y ago
Ah, due to (who would've thunk) the SQLite connection.
- sigzero 6y ago
  That probably had a lot to do with it I am sure.
  - bch 6y ago
    > Ah, due to (who would've thunk) the SQLite connection. The “SQLite connection” is manifold - indeed drh (SQLite author) used to be on the Tcl Core Team, and is an unapologetic user of Tcl. SQLite itself isn’t just “well-supported” in Tcl, it started there. drh calls SQLite “a tcl extension that escaped into the wild”, among other things, and that “...SQLite is still heavily dependent upon TCL and the ongoing support, maintenance, and enhancement of SQLite would not be possible without TCL, and would be seriously inconvenienced without Tk.” [0][1] The ties are interesting and deep. [0] https://sqlite.org/tclsqlite.html https://sqlite.org/tclsqlite.html [1] https://www.tcl.tk/community/tcl2017/assets/talk93/Paper.html https://www.tcl.tk/community/tcl2017/assets/talk93/Paper.htm...
    - sgbeal 6y ago
      > The ties are interesting and deep. Brad! You're alive! In case you hadn't heard: libfossil was recently revived, has been brought up to date with regards to SHA3 hashes, and got both "update" and "revert" APIs within the past week or two. The "last" major day-to-day feature it's missing is merge. We have the merge algo (it's used by update), but not yet the equivalent of the merge command. Your account is still active on the repo (https://fossil.wanderinghorse.net/r/libfossil https://fossil.wanderinghorse.net/r/libfossil).
      - bch 6y ago
        I’ll ping you offline. I’d love to get back to that with you. Also enjoy seeing your comments all over this article :)

KwanEsq 6y ago

SQLite famously does so: https://www.sqlite.org/cgi/src https://www.sqlite.org/cgi/src

mgreenleaf 6y ago

I use it for most of my projects, with git covering the rest of them. I prefer the cli usage, philosophy, single binary / single file repository, and having all the notes/issues transfer across when I push makes it easier to develop and test across windows/linux/bsd. Autosync and other things are well-thought out details too; generally feels well designed. Otherwise, day to day usage isn't much different.

emodendroket 6y ago

It seems to me like you’d want it to be obviously way superior for some reason to go so far away from the herd.

mscrnt 6y ago
You’d forsake an improvement for the sake of following the rest of the cattle? Have you used it, yet, to see if it sufficiently meets your way superior standard to break free from the herd?
- emodendroket 6y ago
  Well yeah because git is, I find, good enough that I don’t have much desire to experiment with other SCM tools. Some people love customizing every part of their tool chain but to me it’s better to stick with something familiar with things like that so I can focus on solving my actual problem.
  - mscrnt 6y ago
    But have you tried Fossil to see if it does meet your way superior standard? Unless you're working on Linux kernel- or BSD-sized repositories, Fossil is arguably a better fit than Git. You don't need to customise anything out of the box—it's literally a single binary anywhere on your path and you have your version control, bug tracking, wiki, forum, chat, technotes, etc. in-house. Your team won't need to visit but one server—that really streamlines focusing on solving your actual problem.
    - emodendroket 6y ago
      Pretty much everyone already uses git and some kind of issue tracker so the question is more if it's so much better to justify learning a new thing, not if it is slightly better in the abstract. It is not immediately obvious to me that bundling all these things into one tool is going to give better results, especially when you have non-developer users in the mix.

Hendrikto 6y ago

Fossil looks very interesting, but I completely disagree with their [stance on rebasing](https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md). This is a dealbreaker for me. I do not consider having 10 buggy commits per feature instead of 1 working one an advantage. It just complicates reading history and hinders debugging (e.g. bisect). I get their arguments, I just disagree.

rubyist5eva 6y ago
This is what private branches are for - when you merge them and sync they show up as a single commit on the mainline branch - not too different from git merge --squash.
- mscrnt 6y ago
  That, and it's very easy to hide commits from the timeline too. You can get most if not all the benefits of rebase without losing history—that's a good thing.
- deleted 6y ago
  [deleted]
iudqnolq 6y ago
The theory is that you don't see those 10 commits unless you choose to. I think they're right in theory that a Sufficiently Smart^TM scm should be able to work better by not throwing data away, but I haven't tested if it actually works in practice. > The Git documentation acknowledges this fact (in so many words) and justifies it by saying "rebasing makes for a cleaner history." I read that sentence as a tacit admission that the Git history display capabilities are weak and need active assistance from the user to keep things manageable. Surely a better approach is to record the complete ancestry of every check-in but then fix the tool to show a "clean" history in those instances where a simplified display is desirable and edifying, but retain the option to show the real, complete, messy history for cases where detail and accuracy are more important.
dahart 6y ago

theamk 6y ago

I avoid it because of complete lack of commit amendment tools. It seems like quarter of the time I make a commit I mess up either a commit message or a file list, and have to "git amend". I have no idea how the sqlite devs live without the feature, they must be much more careful programmers than I am.

mscrnt 6y ago
You could always try "fossil amend" as a commit amendment tool for starters.
rkeene2 6y ago
There has pretty much always been a way to amend commits -- the difference is in Fossil this amendment is done by writing a new journal entry (artifact) noting which commit is being amended and how, rather than modifying the commit directly. Generally, the compiled version (base+resultant set of amendments) is displayed to the user, but the entries which modified the commit are also available to be seen.
- everybodyknows 6y ago
  >modifying the commit directly. Git preserves a record of the origial commit, plus amendments leading up to the final - git-reflog. The reflog is however subject to periodic pruning by default - see git-gc.
  - rkeene2 6y ago
    Fossil preserves the journal of activities forever, and across clones.
sgbeal 6y ago
> I avoid it because of complete lack of commit amendment tools. That's downright wrong: https://fossil-scm.org/home/help/amend https://fossil-scm.org/home/help/amend

rcarmo 6y ago

I used it for quite some time, still have archived repos on it because they’re a single file and very easy to move around. Mostly moved to gitea on a home NAS for the GitHub sync capability (makes it easy to have a local copy of dependencies, etc.) But I do miss the straightforwardness (and sometimes bluntness) of fossil sometimes. Much easier to deal with for personal projects.

chillfox 6y ago

I use it for any personal projects that are large enough that I want a few pages of documentation and a ticket system to keep track of planned features. The ticket system can be configured quite a bit, so I usually set it up like a todo list with: “to do, doing, done”.

rkeene2 6y ago

I use Fossil and run a Fossil hosting service called ChiselApp [0]. I've used Fossil for all kinds of projects big (commercial Linux distributions, with installer ISO as the result of the CI/CD pipeline stored as Fossil Unversioned content artifacts) to small (a single file demo), but primarily with only a small number of developers. [0] https://chiselapp.com/ https://chiselapp.com/

AnonHP 6y ago
Could you please put up a post on the ChiselApp website about your motivations for running a free service, how you manage it, etc.? It’s always interesting to see these free services without a commercial angle, and makes me wonder why they’re there, how they sustain themselves, what restrictions they impose on users, and related matters.
- rkeene2 6y ago
  I run it because I use Fossil a lot and want a low-friction way to create new repos. It doesn't cost me anything to run since I already had extra CPU, RAM, and Disk capacity on my personal server.

petre 6y ago

Yes, we use it. It's awesome. Thank you again D. Richard Hipp.

silasdb 6y ago

I decided to give it a try on a new project and, although it seemed strange at first (coming from years using git), I fell in love with it and I'm converting all my own projects to fossil. It does everything other SCMs do. It also can do everything git does, but in a saner way. Also, the self-hosting capabilities in a few MB binary are astonishing and you just don't pay for what you don't use. In my own repositories, I don't use chat nor wiki pages, but I do use forum, the ticket system and technotes. The community and developers are very nice to answer questions too, and are open for suggestions. There is room for even further improvement and it is more a matter of someone showing up willing to develop the specific feature of the project.

sgbeal 6y ago

> Does anyone use Fossil? Almost literally every day since Christmas break of 2007. > I like all it offers for the relatively low resource usage. And setting it up to run over CGI (e.g. over a $5/month shared hoster) takes about 90 seconds and requires no additional apps. That was the initial Killer Feature for me, and is still critical for me. i host dozens of repositories over CGI on an inexpensive shared hoster (https://fossil.wanderinghorse.net https://fossil.wanderinghorse.net), and couldn't do that with any other SCM.

zzo38computer 6y ago

I use Fossil for my own projects. However, I do not use the forum feature, chat feature, etc. They don't belong there in my opinion, nor do I like the implementation much; I use external software. There are a few other things I dislike about the design of Fossil; it doesn't have very good low level access, for one thing (there are other concerns too, although rebase isn't one of them). I have started to make my own implementation, which I intend to support the Fossil protocol and deconstruction format. Someone else perhaps had a similar idea, so were writing libfossil; however, they seem to consider the protocol implementation a lower priority, while I consider it important (however, they consider it important to use the same database schema, while I don't, and can freely rewrite it). As it turns out, both of us had independently used the term "deck" or Fossil structural artifacts.

sgbeal 6y ago
> Someone else perhaps had a similar idea, so were writing libfossil; however, they seem to consider the protocol implementation a lower priority, That's me (https://fossil.wanderinghorse.net/r/libfossil https://fossil.wanderinghorse.net/r/libfossil). The protocol is irrelevant to the implementation of the underlying core algorithms and data format. The sync protocol is a completely separate layer which can be reimplemented any number of ways without affecting the underlying data model. Without the core data model and algos implemented, the sync protocol is useless because it has nothing to sync. Ergo: first implement the data model, then the sync. > (however, they consider it important to use the same database schema, while I don't, and can freely rewrite it) That's a really interesting topic, actually. The core data model is 100% independent of any given schema (or storage model, for that matter), so anyone implementing a compatible (at the data model level) tool is free to use whatever storage or schema they want. The fact is, though, that libfossil could never have gotten as far as it has without re-using much of what Richard has already designed, and that includes the schema and core SCM-relevant algorithms. As a long-time fossil contributor, it's important to me that the libfossil tools be as compatible as feasible with fossil, and that means using the same schema (for better or worse). That said: i would very much like to see the core data model implemented on top of another schema, just to see it done. Alas, i don't have the energy to create, from scratch, such a beast, nor to maintain it, so my path is one of lower resistance: re-use what's already been designed and which works well within the fossil project. i'd love to see what you have when you're ready to post it, though. (i recall you(?) posting about this in the fossil forum before - feel free to announce your project there when you're ready.) > As it turns out, both of us had independently used the term "deck" or Fossil structural artifacts. What else would one call a "container of cards"? :)

mscrnt 6y ago

> Does anyone use Fossil? Daily, across a half dozen odd repos, and it greatly simplified my life since switching from Git. My primary wish is to have the forum compatible with email. And the next would be a partial commit option akin to 'git commit -p' although I think this is missed more than it was ever used. At first, I thought the chat was an odd addition but it's being used daily on all repos, and has really improved team cohesion and productivity. The ability to view documentation changes in the browser while still in the local checkout but not yet committed has also proved quite valuable. Having the repository contained in one file is handy, and frequenting one server for all dev related work is a huge bonus. It's unbelievably easy to setup, and the command line syntax and help is highly intuitive and simple, making transition a breeze and continued use a joy. It's a great piece of software for any team working on your typically-sized repo.