I smirked a bit when I saw the URL for hosting but it makes sense if you actually want other people to use/discover/contribute to your project.
Neat idea OP, I am curious about the choice of using fossil as the base. Is there something to it's API, workflow or VCS philosophy that you're attracted by?
I always enjoyed Hg a bit more than git in terms of UI/workflow, but I haven't had much XP with fossil to compare.
Not OP, but Fossil is a bit more than just a VCS, it has built-in wiki, bug-tracker and a bunch of other stuff. And it keeps everything in a single file so it's pretty easy to copy around out-of VCS flows.
This app uses the built-in webserver to show the notes and the JSON api.
It's mostly compatible in abilities, except, famously Fossil is not a fan of being able to change previous commits, while Git is.
Fossil however is mostly incompatible with how Git thinks, since Git is arguably the worst wrapper around an API imaginable, while Fossil is pretty well thought out for smaller dev teams. Fossil will never work for Linux kernel development.
I think it's for the perfect people, who never have to amend commits, never commit to the wrong branch, only work on one branch at a time.. basically closer to SVN than GIT.
If all your git interaction is via "git commit" with occasional "git checkout", then fossil could be an interesting option - it has web frontend with stuff like wiki etc.. built in.
If you start working on "temp1" branch, make dozens of no-message commits and only then carefully make nice-looking PRs out of them, then fossil isn't for you. If you ever used force push to fix mistakes before anyone noticed.. then fossil isn't for you either.
You actually can do most(all?) of this in Fossil, it just puts a big frowny face next to it, and highly encourages you to not change history, for hopefully obvious reasons.
Some of us think actual history is more important than a persons idealized representation of the past.
You could just make a temp2 branch, from master at the same branching point as temp1, and then periodically create your astonishingly beautiful commits from the horridly messy temp1, to temp2. And then merge temp2 to master, when you want.
The only "sin" fossil commits here is that temp1 is still there, if you want to see what you ACTUALLY did (yes, I fully accept that your beautifully crafted commits are totally bug-free).
And here's the real kicker: the fossil ui is easily customizable so that certain branches (eg: "tmp-...") can be hidden from the timeline view, so they don't get in the way.
I believe the sqlite team (inc DRH) have hundreds of "tmp" branches, whose only purpose is "messy commits, clean up later" (yup, you can refuse the same branch name as many times as you like, easier for auto-hiding.
I find the VCS way for notes to have too much friction for little benefit.
You could explore the Fossil's Forum or Wiki way for the notes. This offers the built in editor and some versioning too all without the need to do 'add/remove'.
I used a note system built on top of Fossil as my primary system for quite a while. Here are the details in case anyone is interested.
Fossil allows CGI extensions[1]. There's a database for tickets, but that's just a regular SQLite table that you can use to store anything you want, and it's version controlled and queryable. I stored the notes plus metadata in the tickets database. The CGI returned HTML with the Ace editor for creating/editing notes.[2] Notes were stored using the command line.[3] I needed to add the web server user to the sudoers file to access the Fossil binary.
There were two reasons to use Fossil for this. The biggest was that it handled authentication. The second is that I had a version controlled database to do all the work for me.
I think I eventually moved away from it because I prefer working locally. The "transition" was dumping the data out of the database and into markdown files.
OP is here. First, thanks for all the comments. I am not aware that Fossil supports CGI and it open a new opportunity.
An important reason to use files instead of tickets or wiki is that not all my notes are in plaintext format. I unfortunately have many document in Office format. Therefore, I prefer not to use a system which solely supports text files. I need a system which can keep all the files while allow files to be opened by its application. Any system which do not have a local copy will not work well for me. Fossil does this well: it has a local copy so that files can be opened locally, it can sync to remote site, and text files can be read easily through web interface.
Another reason is that Fossil is local-first. I have written many versions of note keeping system in Rails. It is easy to start with and can be accessed easily. But migrating codes and database is not easy for someone who codes as a hobby. Keeping files in Fossil and synchronizing to other devices is just as easy as zipping all files and unzipping in another device. It is like rsync plus a web server in some sense. So instead of keeping a centralized database and maintaining it, Fossil allows me to work on files and I don’t need to worry about hosting and upgrading a database.
Of course all my comments are highly opinionated and are probably not applicable to others. It is just a demo and I appreciate all the comments. I choose Fossil because I happen to know it. I heard Hg, but never use it. So I cannot comment on the pros and cons.
> So instead of keeping a centralized database and maintaining it, Fossil allows me to work on files and I don’t need to worry about hosting and upgrading a database.
I think I understand what you're saying. Compared to writing a Rails app and connecting it to a Postgres database, it's easier to dump files into a directory and push them to a Fossil server.
Your wording is a bit confusing. Fossil is a database. Adding a file to the repo puts it in the database. fossil ticket add status 'open' comment 'Remember to buy a cat' type 'task' adds a record to the database. You can use the fossil sql command to query anything in the repo.
My heart jumped with joy when I saw this post. Fossil is such an ingenious system, and, if you are not aware, has been created by the very D. Richard Hipp who created Sqlite. Here is a technical overview: https://fossil-scm.org/home/doc/tip/www/tech_overview.wiki
Fossil may never become the VCS that rules the world. But, for note taking, it has some very attractive features:
- it is a single executable, written in C with very litte resource requirements
- the file format (an Sqlite database) is designed as an "enduring file format"
- it has an integrated scripting language
For a very long time now I have been considering to port my own note taking system, knowfox, to Fossil. Inspired by this post I might finally come around doing it.
18 comments
[ 3.9 ms ] story [ 47.4 ms ] threadNeat idea OP, I am curious about the choice of using fossil as the base. Is there something to it's API, workflow or VCS philosophy that you're attracted by?
I always enjoyed Hg a bit more than git in terms of UI/workflow, but I haven't had much XP with fossil to compare.
How compatible is this to git and it's tooling?
Fossil however is mostly incompatible with how Git thinks, since Git is arguably the worst wrapper around an API imaginable, while Fossil is pretty well thought out for smaller dev teams. Fossil will never work for Linux kernel development.
see: https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.w...
If all your git interaction is via "git commit" with occasional "git checkout", then fossil could be an interesting option - it has web frontend with stuff like wiki etc.. built in.
If you start working on "temp1" branch, make dozens of no-message commits and only then carefully make nice-looking PRs out of them, then fossil isn't for you. If you ever used force push to fix mistakes before anyone noticed.. then fossil isn't for you either.
Some of us think actual history is more important than a persons idealized representation of the past.
You could just make a temp2 branch, from master at the same branching point as temp1, and then periodically create your astonishingly beautiful commits from the horridly messy temp1, to temp2. And then merge temp2 to master, when you want.
The only "sin" fossil commits here is that temp1 is still there, if you want to see what you ACTUALLY did (yes, I fully accept that your beautifully crafted commits are totally bug-free).
And here's the real kicker: the fossil ui is easily customizable so that certain branches (eg: "tmp-...") can be hidden from the timeline view, so they don't get in the way.
I believe the sqlite team (inc DRH) have hundreds of "tmp" branches, whose only purpose is "messy commits, clean up later" (yup, you can refuse the same branch name as many times as you like, easier for auto-hiding.
You could explore the Fossil's Forum or Wiki way for the notes. This offers the built in editor and some versioning too all without the need to do 'add/remove'.
Fossil allows CGI extensions[1]. There's a database for tickets, but that's just a regular SQLite table that you can use to store anything you want, and it's version controlled and queryable. I stored the notes plus metadata in the tickets database. The CGI returned HTML with the Ace editor for creating/editing notes.[2] Notes were stored using the command line.[3] I needed to add the web server user to the sudoers file to access the Fossil binary.
There were two reasons to use Fossil for this. The biggest was that it handled authentication. The second is that I had a version controlled database to do all the work for me.
I think I eventually moved away from it because I prefer working locally. The "transition" was dumping the data out of the database and into markdown files.
[1] https://fossil-scm.org/home/doc/trunk/www/serverext.wiki
[2] https://ace.c9.io/
[3] https://fossil-scm.org/home/help?cmd=ticket
An important reason to use files instead of tickets or wiki is that not all my notes are in plaintext format. I unfortunately have many document in Office format. Therefore, I prefer not to use a system which solely supports text files. I need a system which can keep all the files while allow files to be opened by its application. Any system which do not have a local copy will not work well for me. Fossil does this well: it has a local copy so that files can be opened locally, it can sync to remote site, and text files can be read easily through web interface.
Another reason is that Fossil is local-first. I have written many versions of note keeping system in Rails. It is easy to start with and can be accessed easily. But migrating codes and database is not easy for someone who codes as a hobby. Keeping files in Fossil and synchronizing to other devices is just as easy as zipping all files and unzipping in another device. It is like rsync plus a web server in some sense. So instead of keeping a centralized database and maintaining it, Fossil allows me to work on files and I don’t need to worry about hosting and upgrading a database.
Of course all my comments are highly opinionated and are probably not applicable to others. It is just a demo and I appreciate all the comments. I choose Fossil because I happen to know it. I heard Hg, but never use it. So I cannot comment on the pros and cons.
I think I understand what you're saying. Compared to writing a Rails app and connecting it to a Postgres database, it's easier to dump files into a directory and push them to a Fossil server.
Your wording is a bit confusing. Fossil is a database. Adding a file to the repo puts it in the database. fossil ticket add status 'open' comment 'Remember to buy a cat' type 'task' adds a record to the database. You can use the fossil sql command to query anything in the repo.
Fossil may never become the VCS that rules the world. But, for note taking, it has some very attractive features:
- it is a single executable, written in C with very litte resource requirements
- the file format (an Sqlite database) is designed as an "enduring file format"
- it has an integrated scripting language
For a very long time now I have been considering to port my own note taking system, knowfox, to Fossil. Inspired by this post I might finally come around doing it.
There are also embedded docs if you want to bring your own editor.
https://fossil-scm.org/home/doc/trunk/www/embeddeddoc.wiki