It can do this, including a kind of “single sign-on”; see this page and search for the phrase “multiple repositories”.

it looks like Fossil can't manage multiple repositories at the same time

Would you mind saying which pages you're looking at which give that impression? I or someone else may be able to improve them to avoid this misapprehension.

There are in fact at least three different ways to achieve your desired end:

1. Use fossil server in directory mode. (See paragraph 3 on that linked page.)

2. Run Fossil in CGI mode, with one CGI script per repository. The script is trivial, and is given at the linked page.

3. If you're integrating this with an existing web site but want Fossil to run continuously for lower startup latency, you can do as I do, and run Fossil in SCGI mode, with your web server configured to proxy content under certain top-level directories to Fossil instances bound to localhost on separate TCP ports. See my fslsrv script below, which quickly and easily launches multiple Fossil instances for this purpose.

#!/bin/bash
BASEPORT=12345
BASEURL=https://example.com
function start_one() {
    bn=$1
    port=$(($BASEPORT + $2))
    ln="$3"
    url="$4"

    if [ -z "$ln" ]  ; then  ln="$bn" ; fi
    if [ -z "$url" ] ; then url="$BASEURL/$bn" ; fi

    fossil server --localhost --port $port --scgi \
        --errorlog ~/log/fossil/$bn-errors.log --baseurl $url \
        ~/museum/$bn.fossil > ~/log/fossil/$bn-stdout.log &
    echo Fossil server running for $bn, PID $!, port $port.
}

pgrep fossil | while read OLDPID
do
    echo "Killing old Fossil instance (PID $OLDPID) first..."
    kill $OLDPID
done

start_one repo0 0
start_one repo1 1 "A Project Named Fred"
start_one repo2 2 "" https://repo2.example.com/

You will need to customize the base URL at the top of the script and the start_one calls at the end. Notice that you can make it serve everything under subdirectories of a common domain or to put some on other domains. I do a mix of both for my repositories, which is why the feature exists.

You should also pick a different random number for BASEPORT in the 1024-32767 range.

The script assumes you keep your Fossils in ~/museum, because why would you not? :)

I see that my reading was incomplete. I, indeed, totally missed the part "or a directory containing many repositories" in the explanation for the "REPOSITORY" parameter... thank you!

Is there a way to list all "loaded" repositories or will I have to write an index file for that? :-)

Is there a way to list all "loaded" repositories

When you run fossil server in directory mode, it serves every *.fossil file found in that directory. You don't get a choice of which ones to expose and which ones to hide. If you want to serve only some repositories that way and not others, put the others somewhere else.

But there is no "directory listing" built into Fossil, it seems. Everyone still needs to know the URLs. Damn.

You want -—repolist, given on that same page, and in the ”Anonymous” answer below.

Oh.

Yes, I do...

You can have a single set of users/passwords authorized across multiple repos using login groups (/setup_login_group in the web UI).

And a single instance can serve up multiple repos with directory mode.

Other than that, what more do you want? (My own usage is pretty basic so I'm just genuinely curious)

a feature request for a Fossil(Sauron) that can rule them all

It sounds like you want the equivalent of Git Submodules.

There are apparently a bunch of problems with Git submodules, but I don't know enough about it to say whether we could do better with our 20/20 hindsight.

What we have today is fossil open --nested, but that doesn't get you a bunch of features you'd likely want:

1. fossil up should update subrepos as well.
2. fossil ci should check for changes in subrepos as well, probably in depth-first order.
3. fossil open should automatically clone and open subrepos as well. That is, we want a way for multiple Fossil repositories to be logically tied together, so that opening one opens all the subrepos in their proper place. The auto-clone part of this should be smart enough to seek out existing clones and use those if present; else, there should be a configured URL for it to go to to get a clone.

That'll do for a start. There's plenty of ways to elaborate it, but I think that'll cover most of the common use cases.

I brought this up on the old mailing list once, but haven't done so again because it's a corner case for us. We've got one large Fossil repo that requires that a smaller Fossil repo be opened --nested underneath it in each checkout directory, all with the same content. That last requirement is the major reason why we can't just put this subrepo's content into the main repo: the files in the subrepo must have a separate history, not tied to that of the main repo.

the tidy Fossil repo(SQLite db), managed as a collection or project

That still sounds like Fossil subrepos to me.

Let's take this up in a new thread.