Fossil Chat
fossil-scm.org
fossil-scm.org
What it looks like: https://imgur.com/a/PaHExsp
Here's Fossil 2.15 running on EC2: http://54.79.202.57/register - this link will allow you to create a new account.
Alternatively, the "chat" user (password "chat") can be used if you don't want to make an account. [It used to have the ability to create additional users (with admin privs), with the result that the fossil instance rapidly began spouting SQL errors and I had to reset it, twice. That was fun...]
The instance is completely ephemeral. If this comment is more than a week or so old, expect the above IP to be dead (I'll be cycling the VM).
And yes - note that it's going over HTTP, not HTTPS :P (that would have taken an extra, uhh, while)
--
If you're using 'chat': once you've opened the above link, go to "login", login, then locate the new "chat" tab. You can optionally go to Admin > Users and make yourself a new account (the "Add" link is a little hard to see, it's to the far left immediately under the tab bar; also be sure to select "Chatroom" from the far right in the permissions list).
Realizes people can change the password woops <insert cartoon punching fight cloud here> argh
OK. Because Fossil is awesome you can disallow people from changing their own passwords, while also making it possible to create further accounts that can change their own passwords. Nice!
[EDIT: A few misconceptions here. No, you can't do the above; if a user couldn't change their password but could create new admin accounts, said new admin account could just change the initial user pw.]
Too bad it isn't allowed for logged-in anonymous users to chat (though that would be confusing!)
This evening was a fun howtobasic in like 15 minutes
Maybe: Go to the Setup/Access page and select the "Allow users to register themselves" checkbox, and add permission "C" to "Default privileges". Then press Apply. With that setup change, users will have a "Create New Account" button on the login page.
Done, that's a really cool feature.
Drop-shadows, rounded corners, borders, colouring, fades. All extra work, all a pain to look at.
Is like watching Picasso paint a painting on a glass wall, the first half you're "wow this is great", and then you just want to start screaming "STOP! NO! IT WAS BETTER BEFORE!"
i have it on exceedingly good authority (as the one who implemented it) that the look and feel was about 90% personal preference and 10% feedback from other project members during development. The "extra work" you mention is relative - with modern browser dev tools such things can (with a bit of CSS know-how) often be completely styled in a matter of minutes, then copy/pasted over into CSS. The much more time-consuming part was getting the messages to pop up from the bottom, but the difference in readability between that and top-down posts made that effort well worth it.
There's obviously no accounting for taste, but (A) you're the first person i've seen actually complain about the CSS styles and (B) any given fossil site can restyle be restyled to do its admins' personal tastes - they're not stuck with mine.
https://docs.google.com/document/d/135kDqZYb6ZMnUV2ykZSEfNAN...
Short link: https://tinyurl.com/fossildemo
A bit off-topic, but the thing I miss most when I use Fossil (versus GitHub.com) is the ability to do code reviews and leave in-line comments on code.
Also, pull requests [0] would be awesome for some of my more public projects.
[0] https://fossil-scm.org/forum/forumpost/01d77b7259ea0b00b7065...
Currently I only use it for private projects. So my top wish list feature would be basic CI.
[0] https://chiselapp.com/user/rkeene/repository/fossil-ci/index
So what is it for? If it's another inbox to check that's a bit of a productivity drain.
I could understand if it was explicitly designed to compete with other chat platforms. This would seem to fit with Fossil's mission well.
Then the core members don't need to have a dedicated channel somewhere else. If they did, then that would be another inbox to check; instead they can check the fossil chat when they are on the project site looking over commits or documentation.
So it is just another source of information on the main "fossil channel" instead of another channel to check. Viewing it in that way, it is reducing the number of channels by simply inlining it.
But isn't that "a replacement"?
I could see this as a useful feature when you need to chat with contributors once in a while in a less-formal way than issue comments.
It's not an instant messenger, more like a mail box or a bulletin board. Which works when network is down.
Fossil works offline! But leaving a local server up is pretty normal, and that way you get new stuff just as soon as other servers publish it.
Also, and unique to fossil, the server is just... fossil, same fossil that runs locally. No Gogs, no Gitlab, just your fossil, their fossil, and fossil on the server, maybe with a "real" webserver in front of it, maybe not.
The chat room is clearly intended to be run on an always-on server instance, but there's nothing stopping you from setting it up locally and inviting people to jump on your IP. Well, NAT might well be stopping you... but in principle!
I feel that's a bit short-sighted, but I'll admit I'm only a random opinionated passer-by. You can certainly do it, but you'll run quickly into issues and be buried in feature requests because like it or not, a chat room isn't just "a couple messages being passed back and forth"
Hand rolling your own communication tool is a great way to become so busy you don't have time for your actual work.
scm, wiki, defect tracking, a little bit of project management, and now chat room.
The entire idea of fossil is that you shouldn't need to use another website or another tool for anything related to tracking your development. It's the "I am stranded on a tropical island, what do I use for hacking on a project if I can't have github or irc or slack or any other tools out there."
In the context of fossil, chat is just a couple messages being passed around with no account taken at all for any other concerns. It's not a "chat" tool, it's a chat tool for the fossil-scm. Especially if you look at the Ephemeral feature - they delete chat messages after a certain configurable time - so they don't even have to worry about keeping messages.
If I could be so unproductive...
It goes much further than that...
When one views a fossil-hosted forum post from the main fossil site or sqlite's site, they are looking at...
- A forum post rendered by software Richard wrote. - Piped out to you via an HTTP server he wrote. - Served from an SCM he wrote. - Stored on a database package he wrote. - All coded in a text editor he wrote.
Complete vertical integration. He's written, or had a majority hand in, every part of the chain except for the browser. We're all awaiting his announcement about his browser project. It's only a matter of time.
It's demonstrably become impossible to manage spam in such an environment without the resources of mega-corps, whereas fossil aims to be a entirely SCM environment in a single binary hosted from modest hardware (e.g. a Raspberry Pi).
The inability to manage spam was the driving factor for the forum. It is somewhat quirky, but it works well and our spam rate has been literally one single spam in nearly three years of operation (and that one was subtle - hiding an ad link inside a markdown hyperlink which enclosed only a single period). Similarly, the sqlite forum (which was migrated only relatively recently) is also spam-free.
If you have found a way to develop a fully spam-proof, mailing-list-based solution then, by all means, show us the code. Until then, the forum has proven to completely solve the problem it set out to: provide a spam-free communication channel for fossil and sqlite.
It's a basic tk-based app, IIRC. i peaked at it once when he posted a link to it, but that was 7+ years ago and i don't recall where it lives. No syntax highlighting, no configurable options (beyond editing the source code), very much built for his personal coding style.
You don't want to leave emacs. Emacs loves you. Trust emacs.
(Disclaimer: i wrote 99%+ of the fossil chat front-end code.)
FWIW...
When Richard (our Alpha Coder) first posted about his proof-of-concept app for the chat feature my inner reaction was very similar to yours. However, writing a chat front-end sounded like an interesting way to spent Christmas, so dove right in.
Now, exactly 3 months later, we've been using chat 24/7 within the Fossil project and i use it heavily on one of my own projects (hosted over CGI, and my biggest initial skepticism was whether chat could work reasonably well that way). Despite my early doubts it's been a genuine help to us within the project. i don't recall us getting more than 1 small feature request since then, and that was cut off the same way the hypothetical deluge would be: point them to the feature's scope document and redirect such users to Discord or Facebook or whatever the cool kids are using these days.
It's been remarkably low-maintenance so far. The only notable development in the /chat code in the past 3 months was the recent replacement of window.fetch with more conventional XHR because of compatibility issues with window.fetch for some clients, and that took all of 90 minutes or so to do.
Building a UI for a minimalist chat interface is easy, but if the standard supports all the fluff features that some people want...
Fossil supports CGI extensions and Thunderbird saves your messages in an sqlite database. I plan to read my email from within Fossil repos. Why? Because I routinely download email messages and commit them to the repo. This will give me a web interface to read messages and, if I want, copy them into the tickets database. I can then query all the email messages related to a project using SQL.
I realize your message was not serious, but it's a real use case.
The only use of it I've seen in the wild is Ripcord (https://dev.cancel.fm/issues), which is interestingly also relatively low resource usage compared to its competitor.
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
[1] https://www.tcl.tk/community/tcl2017/assets/talk93/Paper.htm...
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).
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.
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.
It’s not uncommon to bump into this claim in threads about git, I don’t think the Fossil devs came up with this idea, but they sure are running with it. This is an argument whose time has passed and needs to die. It’s not helpful.
Please @Fossil devs, come up with better and more honest reasons to compare Fossil to git. If I don’t have to rebase again, that’s great! If Fossil avoids merge conflicts more often, and handles merge conflicts better, absolutely fantastic.
But, please, come on. Rebase is “lying” exactly just as much as hitting backspace is “lying”. Am I lying if I fix a typo or a bug before I commit? Do you really want to preserve all keystrokes ever typed on your keyboard during development? Does Fossil actually capture all keystrokes? If not, then are you sure Fossil is not lying about development history by your definition? Being able to clean and organize your development history before you share it with others is an intentional feature, not a bug. Attempting to claim a moral high ground over what is purely a technical and workflow issue is making Fossil look ignorant to me, it’s doing the opposite of what you want.
The history Git and in Fossil is only precise to the transaction level. A key-stroke or backspace is not a transaction. A single iteration of the edit-compile-test cycle is not a transaction. A transaction is created by the "commit" command. Git and Fossil make no record of the stuff that happens in between two commits. They only record what is in each commit. So you can backspace and edit and change all you want to before typing "commit". But once you type "commit", all that you've done since the previous commit becomes part of the permanent record. Rebase violates that constraint. It changes the permanent record. Rebase makes the repository say that the sequence of commits is different from the order in which they actually happened.
You can call that whatever you like. "Telling a compelling story." "Generating a clean history." I call it "lying", since the purpose seems to be to deceive the reader about what actually happened.
It is useful to have a simplified overview of project history, to aid the reader's comprehension. There is no sin in this as long as you are truthful to state that the simplified history is in fact a simplification that skips or revises some of the messy details of reality. The alternatives to rebase that Fossil provides do exactly that - they suppress the unimportant details of the history to provide a simplified and more readable history. The difference is that the original, truthful history is still provided, for auditing and for those who care. In other words, the repository reports both "what we should have done" and/or "the best way to think about what we did" in addition to "what actually happened".
I concede that if you think of a source code repository as just a story or as documentation to help future readers, and not as a accurate history of the project, then rebase is not lying. In that case, rebase is just revising your narrative. But I think that a source code repository should be a true history of a project. If you view a source repository as a true history, as I do, then rebase is a tool for lying about the history.
I never understood why people want to change commit history in Git, so for me it won't be an issue to not have that in Fossil.
Having said that, one point of feedback on the "lying" part: I personally interpret that type of negative phrasing as pointing at a different tool and saying: "Look! They're doing it wrong!"
You make amazing tools, man! There is no need to speak negatively about the behaviour of other players if you're a fantastic player yourself. I'd personally just mention: "Git allows you to change history. Fossil is never going to allow changing history, because that could cause issues X, Y and Z. If you do need to change history for some reason, by all means try something like Git." Keep it factual, and get right back to pointing out what makes Fossil great.
I love how SQLite doesn't downplay any alternatives, it just says: "Look at me. I'm awesome. But if you need to do <unsupported thing>, you probably don't want to use me." It would be great if the Fossil website had that same awesome attitude.
TL/DR: Random guy X that never created a successful product gave marketing advice to the person who created one of the most successful products of all time. Random guy X is an idiot.
> I never understood why people want to change commit history in Git
FWIW, by and large, they don’t, not after it’s been pushed. That’s one of the major problems with this critique.
I don't interpret it as a negative statement about Git or any other version control system. I interpret it as a statement about use of the term "project history" after rebasing. I agree with him, because the phrase "history of the project" implies it's the history of the project, and that's simply not what you have. If you order a cheeseburger and they give you a chicken sandwich, maybe it doesn't bother you since you like both, but it would indeed be lying if someone asks what you're eating and you say it's a cheeseburger.
I once ordered a cheeseburger and got a “burger” without a beef patty or any other kind of meat, not even the veggie pretend meat. Just bread, sauce, pickles and a single slice of cheese.
I felt pretty disappointed with that “cheeseburger”.
Anyway, my point is that the real world lying about cheeseburgers situation is a lot worse than pulling a fast one and handing over a chicken sandwich.
I would begrudgingly have accepted a chicken sandwich.
You don’t want the ability to edit your own mistakes before showing them to other people, even if you find them before you push?
Fossil is not capturing my pre-commit keystrokes, so I can write code and delete it without turning it into a ‘transaction’. Is that lying?
What’s sacred about my local branch before I push? In practice, nobody rebases things in public branches except by accident or to fix big mistakes. Rebase is almost entirely a local pre-push workflow. Why should I be preserving my local pre-push history, and why are you calling that “project history”?
If “project history” is so sacred that all commits should be declared immutable, how do you suggest fixing accidents like someone checking in SSH keys? Is it impossible to fix security accidents in Fossil? If so, is that good?
Why is the word “lying” being used instead of saying something like “the project’s history of transactions is being changed”? Do you think the phrasing is not intentional? Do you believe it’s good faith to accuse tool writers and tool users of being deceitful for just using a tool the way it’s designed? Do you believe the write up on rebase is impartial?
I don't feel like it was clearly explained, which is why I asked those questions. There's no distinction between local private history and public history shared with others, there's no explanation for the arbitrary line drawn on transaction boundaries, or why those are more sacred than other kinds of project history. There's no clear explanation of why "project history" should be immutable, or even what constitutes "project history" exactly. It sounds generally like a good idea to keep history to me, heck I'm on board! But the reasons to be absolute about it have not at all been clearly established, only stated dogmatically.
Everyone jumping on me is defending the use of the words "dishonest", "fabricate", "white-wash", "lying", and "deceive" as though they're merely accurate and not what they are: intentional attempts to induce shame about rebase. My point is, simply, that this is spin and it's misplaced because git was not designed to take away your freedom to modify your commit history.
Do you have any better reasons to avoid rebase that don’t depend on your own negative interpretation of git’s design intent, an interpretation that contradicts git documentation?
You could be focusing on positives instead of trash talking. You could be talking about the interesting idea of providing multiple views of history, one un-editable for details and one editable for presentation. That’s interesting and useful. Instead you choose to take cheap shots at a system that was designed differently than your ideal, without acknowledging its intent. You are breaking Hanlon’s razor and consciously choosing to assuming malice... for something that has a written history of discussion about why it exists.
Are you aware that rebase openly advertises the fact that it reorders commits, and was designed that way intentionally? Are you aware that git openly makes zero guarantees about the order of transaction events, intentionally, to allow me to have control over my presentation? Are you aware that rebase is primarily used on local commits before push, and not often used after push?
I would speculate that you are aware of these things, and not simply ignorant about git. If so, that means you are lying here and now, if not it means you don’t know what you’re talking about. I think you know git’s design intent, so it seems like you are intentionally misrepresenting the design intent of rebase. The only deceit here is coming from you, ironically.
Who are you lying to, if the other people on your team expect your merges to be rebased before you push?
What history is being lied about, if no one every saw if before it was pushed, and it is never rebased after being pushed?
Rebase is not intending to trick someone, it is not concealing a truth that needs to be otherwise preserved. Rebase is not hiding something that should not be hidden. Rebase is for cleanup and fixing mistakes.
Please stop using inappropriate words. It’s completely fine to preserve your messy edit history. It’s completely fine to want to preserve your mess. But it is not “lying” to clean it up before you push.
It’s funny you suggest I’m rephrasing it, when you are the one using different (negative) language than the git manual.
rebasing is "rewriting history". where I'm from "rewriting history" is lying..
The Fossil manual is pretty clear about calling it deceit. “By discarding parentage information, rebase attempts to deceive the reader about how the code actually came together.”
> where I’m from “rewriting history” is lying...
What history? Rebase is normally used before push. Rebase is used before it’s “history” to someone other than yourself.
I don't even care that Fossil is attacking the competition, really. I am a huge fan of SQLite. I just wish this silly "lying" argument would go away. It does not put Fossil in a good light. It does not make a meaningful contribution to understanding version control workflows. It does not give git (or any other VCS) the benefit of the doubt or it's due credit in the context of it's own design decisions, even if those design decisions are inferior by today's standards or in Dr. Hipp's opinion. But, it's clear I didn't make any progress here, I'll just think about why I'm not being persuasive and try again later. This claim about lying would be just as "true" but even sillier applied to Perforce or Subversion or RCS or SCCS... think about it.
Also for the online Fossil docs, which are great.
I can’t say I agree with this though.
> If you change the history to something that is materially different, which rebase does, then you are lying about the history. You cannot white-wash this fact.
I use rebase to clean up the history of my feature branches before merging to release branches.
In that sense I don’t see a moral difference between not committing my work at all until it’s complete and rebasing. It doesn’t seem like any more of a rewriting of history than just editing text before each commit.
The nice thing about rebasing is that future readers don’t need to see the 20 commits I created titled “wip” just so I could back up my work at the end of the day or push to a test server.
This is exactly the kind of dishonest hyperbole daheart mentioned.
The purpose isn‘t to deceive the reader. Does the reader really need to see the "tmp" commit I made when switching from my desktop to my laptop? I do not think so, and squashing this commit is not intended to deceive anybody. Your comment on the other hand…
In my view, what I am doing with rebase is creating project history, not changing it. The history becomes immutable and "the truth" once the feature branch is merged.
> I think that a source code repository should be a true history of a project.
You repeatedly claim this without justification. Seems like many people do not see the value in "WIP" and "tmp" commits and failed design decisions littering history.
You do provide good reasons for why this isn‘t useful though:
> So you can backspace and edit and change all you want to before typing "commit"
So you agree correcting mistakes is useful, and not everything should be recorded.
> It is useful to have a simplified overview of project history, to aid the reader's comprehension.
> I concede that if you think of a source code repository as just a story or as documentation to help future readers, and not as a accurate history of the project, then rebase is not lying. In that case, rebase is just revising your narrative.
Exactly.
Consider "I ate a sandwich." vs "I though about eating a watermelone (typo), but when I opened the fridge, I changed my mind and decided to make a sandwich instead. During the process I dropped my knife on the floor and had to clean it. Then I ate a sandwich."
The second one is a much more detailed and truthful account of what happened, yet it does not provide any value. The first, much shorter and easier to follow, history conveys exactly what I wanted to tell you: What I ate.
[1]: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md
I haven’t been entirely persuasive here, so I’m reflecting on how to better elaborate my thoughts. The singular word “lying” isn’t really the main thrust of my objection.
Maybe the biggest issue I see still there is the assertions about the intent behind rebase, which means the intent of git’s developers and git rebase users. It’s not really true that rebase intends to “deceive”, that’s not how the authors of the feature talk about it or frame the feature. In my opinion, it’s a semantic cop-out to claim the words are factual and non-judgemental, when the negative thrust of your choice of language is evident, and when there are clearly less loaded words available to you.
It is in that sense - your assertion that the primary intent behind rebase is to deceive people - that I feel like the Fossil documentation is still not being particularly truthful with the facts.
One way to look at this is to ask what would happen if git removed rebase. Right now, if that happened, and git didn’t change anything else about it’s design, it would be somewhat frustrating and unusable. Rebase doesn’t exist on an island, and removing it would have negative consequences, and need to be replaced with other features. Git doesn’t have a way to present a clean history without rebase there. It would be awesome for Fossil’s story to note how the fundamental design is an improvement over git.
I know your framing and language is intentional because you believe strongly in the idea of preserving project history. That is an acceptable, even laudable goal. I’m for it. Git did not have that goal when it was designed, and it’s not fair to selectively leave out that fact when criticizing. Aren’t there better ways to make the point without presuming to proclaim what the intent of rebase is? Can’t the harmful implications of rebase be demonstrated rather than framing it as “fictitious”, “fabricated”, “counter-factual”? Could you talk about it without accusing innocent bystanders of “white-washing” and being “untruthful”?
BTW, I think the Pro Git book commentary isn’t that fair to hold up as evidence for two reasons - they didn’t design rebase, and they are also trying to softly address the very argument you’re putting forward, because it keeps coming around. The existence of their comments doesn’t somehow prove that git designed rebase to “lie”, it only shows that they heard you.
This is a false dichotomy. You can have it both ways - git just doesn't provide it both ways.
In Mercurial, you can squash commits so the history shows it as one commit, but you can still see the individual commits if you really want to. The history is never lost. I imagine Fossil does something similar.
Looking at this subthread: Wow! People really get triggered when it comes to Git.
Serious question though: what do you do in Mercurial, or Fossil, when someone accidentally checks in SSH keys? I’ve watched this happen in companies multiples times.
So... there's both shun and scrub in Fossil, which lie about project history? Or is is not accurate to call it lying in this case?
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.
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.
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.
That's downright wrong: https://fossil-scm.org/home/help/amend
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.
The ticket system can be configured quite a bit, so I usually set it up like a todo list with: “to do, doing, done”.
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.
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.
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), and couldn't do that with any other SCM.
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.
That's me (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"? :)
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.
I tried to created an account to see it live at https://www.fossil-scm.org/home/chat but it appears they have /chat locked down to authorized accounts.
(Regardless of what others might be saying in this thread, I think this functionality is great. It reinforces the centralization of your dev related work. Plus, presumably they are using SQLite on the backend - so /chat might result in now additional functionality being added to SQLite that might also be beneficiary e.g. removing blocking on writes, etc)
As for the dream of making SQLite faster or better, I doubt it. Fossil works best for small teams with projects sized reasonably for those teams, and chat privilege isn't generally given out to the masses. There's only one chat room per repo. Therefore, there simply isn't enough I/O involved to drive much in the way of SQLite changes.
Fossil proper has resulted in SQLite improvements, though, such as the recursive CTE feature added in 3.34.0. That directly supported a feature for tracing the history of files through renames across repository history using a single efficient (though complicated) SQL query: https://fossil-scm.org/forum/forumpost/5631123d66
Perhaps a better iteration would be as a consistent proxy to other chat hosts? As in, once configured, this chat feature would mirror to IRC, Slack, Discord, Telegram, Google Hangouts, etc.
Fossil users could have barebones but consistent access to team chats without the multiple inboxes problem? Or they could use the established chat host directly and never look at this chat again.
It's literally the most used database in the world, but a giant margin. Every Android and iOS device and every mac and linux machine use SQLite. I haven't ever bothered to check Windows, but I bet they use it too.
As is stunnel, which is what the canonical fossil website uses to handle HTTPS
If you want something more complicated (BSD jails, Docker, etc.) the same properties make it easy to box up that way instead.
(1) Fossil is designed to run inside a minimal chroot jail. The stand-alone "fossil" binary needs its repository database file, /dev/null, and /dev/random and nothing else. It can run inside a sparse jail. So even if somebody manages to find an RCE in Fossil, the damage potential is limited. They cannot shell-out because there is no /bin/sh in the jail.
(2) Fossil processes each HTTP request in a separate process.
(3) Custom static-analysis tools run over the Fossil sources at compile-time, and abort the built if any problems are seen. The source code and docs to these tools is in the Fossil source tree.
Fossil's been available for nearly 14 years now and we've had to make only a single security-relevant release in that time (in late Summer 2020).
Fossil's primary architect, Richard Hipp (edit: HN user "SQLite"), is no stranger to code hardening and continues to add security-related APIs to all levels of the code, from how we internally build SQL queries or encode URL arguments to the recent (late 2020) ability for the db to lock down regions of the db until/unless that protection is toggled off for the brief blocks of code which need to modify those regions, ensuring that other areas of the code cannot modify parts of the database which they aren't directly responsible for. Security against malicious inputs has never been treated as an afterthought in fossil.
Also one more extra letter to type for people who can type 100+ words per minute and over an entire day probably only need to type 2 words per minute on average (the rest of the time spent thinking, debugging, reading documentation, being in meetings, etc) :-)
I was today years old when I learned I was a character device.
I'm not surprised; I do emit a lot of bytes all day.
You forgot to mention vfile.chnged. i've been contributing to fossil since 2008 and that missing "a" still, to this day, agitates me ;).
fossil: messaging over version control
edit: Oh haha, the website is literally Fossil. Ok but I wanna see what the chat UI and other stuff looks like.
It isn't clear what makes bundling a chat program into your SCM beneficial. The only benefit I can see is linking to other things in the SCM like wikis and issues, but since these are available on the web anyways you can just use regular URLs in any old chat app.
The other possible benefit would be keeping chat with you for local searching and keeping it with the history of the repo, however this is designed to be ephemeral so throwing that possible benefit away. (I guess you are supposed to use Forums for that https://www.fossil-scm.org/home/doc/trunk/www/forum.wiki)
I'm not a Fossil user, so maybe I just don't understand, but I see little to no value in this feature.
But one workflow for it would be open source projects that prefer not to have to maintain additional infrastructure and just want to inline ephemeral communication w/o having to keep it forever; then they make a design decision and have everything that is finalised moved over and documented in the wiki.
You just answered your own question: trying to get any given group of people to use the same 3rd-party chat platform, especially one hosted by Big Megacorp (and aren't they all nowadays?), is like herding cats. Every developer on a fossil project already has an account they can use, not hosted by Big Megacorp, which they can chat over (provided the project admin permits it - they are not required to give devs chat access).
i admit that i had several reservations when Richard proposed /chat on the fossil mailing list, but i'm a 100% convert, and now use it 24/7 on two projects and get tremendous value from it.
(Disclaimer: i wrote the /chat front-end, so am inherently biased, but i'm biased towards it because it's useful, low/zero-maintenance, and low-friction, not because i've invested many hours into its development.)