Author is saying goodbye to Fossil, but doesn’t state where he’s going from there. I’m very curious where he lands.
Exactly, it doesn’t propose any alternative, and it doesn’t react to any recent change in Fossil either. I’m not sure what the point of such a post is.
I currently use fossil for a side-project, but I’ve been keeping an eye on self-hosting git servers, mostly for easier github mirroring. gitly is the one that currently has my interest, as it’s the only git server that seems to have the features close to what fossil and is built to run on servers with less an 1GB of RAM, (as opposed to Gogs or Gitlab).
I wonder what it would take to rectify these things in fossil itself?
Does Gogs (or Gitea) require that much resources?
Not for basic usage, but gogs (at least) has other strange performance issues. For instance, every time the file tree for a repository is loaded, it checks the git history for the last commit to modify that file. On tiny repos, this isn’t too bad. However with a 100-200 file ASP.net website, the file tree (front page for a repository) can take 5-7 seconds to open, with no load on the server. I don’t want to put something like that in front of the internet. Gogs doesn’t target a low resource use case, where fossil does. And, according to their press release, it looks like gitly does as well.
I know this isn’t as turnkey as Fossil, but if you set Gitea (and I assume Gogs) to use any form of cache other than 60-second in-memory, the file tree shouldn’t be as expensive. Been awhile since I played with this, but I remember hitting and quickly resolving the same issue.
https://github.com/gogits/gogs/issues/1518 is an issue covering it in Gogs.
Looks like gitea is still in the process of working on it as well, or at least something similar https://github.com/go-gitea/gitea/issues/502
Is the caching that you’re talking about something akin to 20-minute caching in memory, or do you need to go for redis or memcached for this?
They say that you can run it at a basic level on a Raspberry Pi, but that a 2 core / 1GB RAM server is the baseline for teamwork. That’s not very descriptive, to be honest, but on my 512 MB ram server, I’m not exactly curious to find out, since fossil is currently working for me (if there are compelling reasons to switch away from fossil, I will). It could be that 1 GB is just for teams of 20+ people, or just a comparison based on bottom tier Linode instead of something like Ramnode or Vultr, but I don’t know.
If Gitea were 100% Go based, I’d suspect that the 1GB is actually plenty of headroom, but it also interacts with git, and currently has the slightly strange file tree browsing issues that haven’t been locked down yet (as mentioned in other comments).
This is in strong contrast to fossil, which explains how it an be used in a shared host CGI environment. It also explains which actions can be rather slow (mostly building tarballs/zip archives, and it offers a cache for those).
It also helps that the default page for fossil doesn’t show a directory listing, but that’s another discussion.
I just looked at gitly and it seems super shady. Author claims it’s open source, but where’s the source code? The link to file a bug is a web form, why not an issue tracker?
I’m watching and interested it, but I’m not sold on it yet. I won’t be using until it is properly open sourced, but the claims that he is making are worth like they’re worth watching.
As far as the lack of source and the use of a web form, I think it’s a bit early to call it shady rather than just MVP, at least for now. It’s not confidence inspiring, to be sure, but I’ll give him the benefit of the doubt until April 10th. Fossil isn’t going anywhere, and is serving my side-project needs just fine for now.
EDIT: It looks like one of the example repositories, from Tensorflow, has been removed in some fashion. Something does seem to be afoul.
I don’t know. To me, MVP would be a GitHub / GitLab / Bitbucket repo with source and an issue tracker, not a marketing web site. But who knows, it’s an interesting pitch in any event. If the guy pulls it off it will be pretty useful.
Wow. RSS is basically unusuable for a ticket system. How many feeds are people going to subscribe to? And it’s not like you can unsubscribe. What if the bug is reopened?
RSS readers have zero trouble with many feeds. Fix your client if adding new ones is hard. Unsubscribe if you no longer care about the ticket.
That said, I prefer email to RSS (my RSS reader is just an email bridge).
Gitlab for example emails you when an issue you own or subscribe to is modified, just provide an RSS feed based on that.
Per user feeds are certainly workable, but it doesn’t sound like that’s what fossil offers. Only per bug.
I’ve actually migrated my code to fossil recently. Fossil seems, in general, like SCM done right.
My biggest gripe with fossil is it’s broken merge. As much as I loved the concept of having SQLite as your storage engine, and 1 binary being able to do everything, I really hate the sync, and merge conflicts story. Even at my own; working on two different machines and syncing changes have been painful. I would say I have been spoiled by git, with it’s powerful concepts. I wish somebody makes a fork out of fossil and brings some git goodness over :P
What specifically has happened that has caused these problems? I’ve used fossil a bit for personal projects, and haven’t ever had a major merge problems, at least yet, so I’d be interested to know what kinds of things lead to problems (if for no other reason than to avoid them myself).