Practical aspects aside, having issue tracking in the repo prevents lock-in of that data - in the way that the github platform works, for example.

This is exactly what intrigued me and made me switch to Fossil. I don't want to have my issues, wiki etc. held hostage by some company. And if someone wants to fork it, they should be able to fork it including issues and wiki.

Self host Gitea?

I use fossil mostly as a Customer/Project KB/Documentation tool, when a new project starts i have all the documentation, code snippets/examples in one single file, when the project is finished, i have to give one sqlite.db file over to the customer and that's it. LOVE IT, a really great tool!

I was astonished and appalled to find that your Github bugs, wiki, and PRs were not all in your repo.

I think you can sync the wiki if you want:

  git clone https://github.com/project/name

would have a wiki:

  git clone https://github.com/project/name.wiki

I don't know if this is a special setup or not.

Will they remove this?

Are there ways to get to other stuff?

> The idea of having everything in one repo, incl. bugs, is just great. I can create new bugs while offline, update bugs while offline, etc. and then just sync everything once I'm back online.

The bug thing I kinda disagree with... or at least I'm skeptical, shall we say. Bugs are solved when the fix has been deployed and verified fixed in production, not when someone commits/pushes/merges a potential fix to the main branch. Sure you can separate the 'bug-X fixed' change to the bug tracker and the code commits, but then what have you gained over just a 'Fixes: X' annotation in the commit msg?

This could be misunderstanding on my part about the intent/process around bug/issue handling in Fossil, so I'd appreciate if you could expand on what you like about and how it works within the larger 'deploy a fix' context.

(I tried Fossil for a bit on a very small scale -- it was pleasant enough, but ultimately Git's network effects win out big time... at least for me.)

It isn't putting your issue tracking into an equivalent of a git repository. It just contains a rather standard-looking issue tracker, along a wiki for documentation, in the same sqlite. And they are distributed/synchronized just like the repository.

So they're independent of what happens to the code and just happen to be bundled/synced when the code is?

yes

Ok, makes sense, but what is the workflow like, then? Would one close the bug along with the fix to the code, or...?

If you include the ticket ID e.g. [ticket-id] in the commit's description, the commit will automatically be linked to that ticket. You can view the list of all associated commits with a ticket by clicking the 'Check-ins' menu item on the ticket's page. When an item is closed - the link appears struck-thru.

I dont automatically close tickets on commits - since our workflow is commits get reviewed before closing an item- but it is straight forward to write a small few line script to do this if thats your workflow.

Whatever you like. Workflow is a layer on top.

That is only true for projects where you need to deploy. In that case, yeah, you of course can only close the bug once you fixed production. But for normal software development, you can fix the bug in the software and you can update the bug tracker, and then push everything once you're back online.

For example, on a flight, I can look at the bug tracker (since it's part of the clone), pick a bug I want to work on, create a few commits to fix it, then update that bug (set it to closed, reference the commits that fixed it), and then upload it all when the plane landed again.

This is really nice. How have you been hosting this? How well is fossil able to handle the traffic?

I've read so many articles about the advantages of static site generators and serverless implementations for blogs so that they are able to handle traffic and the insane amount of tooling around each of those concepts. It's so great to see a well crafted piece of software being able to take care of all that so seamlessly.

I'm a big fan of fossil personally and use it for all my projects as well as for all the projects in our organization.

A lot of us Fossil users host it on $5 VPSes. It's written in C atop SQLite, so the network is almost always the bottleneck, not the server-side processing speed.

sqlite.org and all of the other repos D. Richard Hipp maintains (Fossil, Pikchr, the separate SQLite docs repo, the forums for Fossil and SQLite...) all run on a $40/month VPS. The page generation time is calculated and displayed at the bottom of non-static pages like this one: https://sqlite.org/src/

This is running on a server with super slow single core performance and slow I/O (Sun Fire T1000 with full disk encryption, giving ~ 2 MB/s for the disk), and yet it feels fast and I've never encountered any performance issues. As long as your repo is not as gigantic as https://pkgsrc.fossil.netbsd.org, you'll be fine, no matter what slow hardware you throw at it.

>Sun Fire T1000

Oh YESS!!! Can i ask what OS you use on it?

BTW CoolThread ;)

Thank you for posting a link to your site. It's really nice to see a live demonstration of Fossil. I notice that your page is using https - does Fossil do that or do you have something else in between (nginx, etc) that provides the https?

Crypto is something best delegated to others. There are a bunch of ways to host Fossil, several of which offer HTTPS proxying: https://www.fossil-scm.org/home/doc/trunk/www/server/index.h...

Yeah, I'm just running `fossil server --scgi` in a chroot and then use nginx for TLS.

Another option is running is behind Apache as a CGI, and let Apache handle the HTTPS part. My repos (fossil.wanderinghorse.net) all run as CGIs on a $7/month shared hoster, and have been since 2008, without issues.