Fossil (<a href="https://fossil-scm.org/home/doc/trunk/www/index.wiki" rel="nofollow">https://fossil-scm.org/home/doc/trunk/www/index.wiki) solves this pretty nicely. You can have documentation as files or in a special wiki namespace and it's versioned both ways, and every repository clone gets everything. Even better than that, your in-tree documentation files are rendered and browseable in exactly the same way as the dedicated wiki namespace.
The linked URL to the home page there can even serve as an example: the "trunk" is a check-in name (<a href="https://fossil-scm.org/home/doc/trunk/www/checkin_names.wiki" rel="nofollow">https://fossil-scm.org/home/doc/trunk/www/checkin_names.wiki) that points to the newest check-in on the "trunk" branch. You can replace it with any other reference to get the old version; eg, version-2.20 would work to get the version 2.20 of the docs, 2015-03-14 would work to get the version from 14 March 2015, etc.
Yep, I use Fossil for all my side projects. Super easy to host, tiny, includes everything I need for a project, all in one file. Great piece of software.
I've been gradually migrating my Git repos to Fossil as I've been touching them. Been quite happy with it.
There are only a couple things that I miss:
- Grouping repos together into a combined project. I'd love to be able to have a single Fossil server/instance with a single set of users, wiki pages, tickets, etc. but multiple independent codebases. Closest I've gotten to that is to simply have multiple independent branches instead of a single trunk (example: <a href="https://fsl.yellowapple.us/avorion/home" rel="nofollow">https://fsl.yellowapple.us/avorion/home), and it's worked surprisingly well, but it's clear Fossil wasn't designed with this workflow in mind, so there are some rough edges with it (albeit minor and easy to work around).
- Compatibility with things that assume you're using Git. Being able to export to Git helps a lot here, but it's still extra steps. Ideal solution here would be for the Fossil server to be able to double as a Git forge and present repos accordingly, such that I can point things like CI/CD pipelines or Terragrunt module calls or whatever directly to the Fossil repo itself over the Git interface those things expect instead of having to setup a Git forge manually and somehow synchronize everything w.r.t. access controls.
- An equivalent to Git's submodules. This would IMO help address the “grouping repos together into a combined project” case as well.
There are login-group options which lets you have a single sign on with a group of repos, To unify the other bits it looks like it would be possible to change the main menu links to the central repo(in the web settings).
Never wanted to do what you want but it sounds possible
set up the fossil server on a directory of repos probably with --repolist to get a list
fossil server --repolist /var/fossil/
get all repos in the same login-group
change the menus in each repo to point to the core repo. Based on some quick tests I suspect a full http:// url is required.
- Forum /forum {@2 3 4 5 6}
+ Forum https://mydomain.org/core/forum {@2 3 4 5 6}
chungy · · focus · HN ↗
The linked URL to the home page there can even serve as an example: the "trunk" is a check-in name (<a href="https://fossil-scm.org/home/doc/trunk/www/checkin_names.wiki" rel="nofollow">https://fossil-scm.org/home/doc/trunk/www/checkin_names.wiki) that points to the newest check-in on the "trunk" branch. You can replace it with any other reference to get the old version; eg, version-2.20 would work to get the version 2.20 of the docs, 2015-03-14 would work to get the version from 14 March 2015, etc.
mghackerlady · · focus · HN ↗
rpdillon · · focus · HN ↗
yellowapple · · focus · HN ↗
There are only a couple things that I miss:
- Grouping repos together into a combined project. I'd love to be able to have a single Fossil server/instance with a single set of users, wiki pages, tickets, etc. but multiple independent codebases. Closest I've gotten to that is to simply have multiple independent branches instead of a single trunk (example: <a href="https://fsl.yellowapple.us/avorion/home" rel="nofollow">https://fsl.yellowapple.us/avorion/home), and it's worked surprisingly well, but it's clear Fossil wasn't designed with this workflow in mind, so there are some rough edges with it (albeit minor and easy to work around).
- Compatibility with things that assume you're using Git. Being able to export to Git helps a lot here, but it's still extra steps. Ideal solution here would be for the Fossil server to be able to double as a Git forge and present repos accordingly, such that I can point things like CI/CD pipelines or Terragrunt module calls or whatever directly to the Fossil repo itself over the Git interface those things expect instead of having to setup a Git forge manually and somehow synchronize everything w.r.t. access controls.
- An equivalent to Git's submodules. This would IMO help address the “grouping repos together into a combined project” case as well.
somat · · focus · HN ↗
Never wanted to do what you want but it sounds possible
set up the fossil server on a directory of repos probably with --repolist to get a list
get all repos in the same login-groupchange the menus in each repo to point to the core repo. Based on some quick tests I suspect a full http:// url is required.