I can't tell if you're asking for one feature or two. Is the wish for a single unified repo DB file just your idea of a way of unifying login details, or do you want it for some independent purpose?

The unified login scheme does exist in Fossil: Admin → Login-Group.

A Single DB file to have multiple independent repositories

No. All user accounts/access permission in one repository db have access to everything in that db. There is no way to tell fossil that Bob can only check in to abc/ while Alice can check in to abc/ and def/.

A repo db in fossil is an atomic unit, in the sense that it cannot be broken down into multiple independent "zones" or "subprojects". Any such partitioning of a project tree is a project-level policy, not something fossil can enforce.

If you need projects with different permissions/users, use multiple repos and, like Warren said, login groups.

Maybe we should add better docs for login groups - more than just the manpage.

i'm not certain that anyone other than Richard is familiar enough with them to do that :/. (i've never used them, though the recent addition of a CLI interface makes them far more appealing to me than they used to be.)

LOL! It was posted as anonymous, so i didn't realize it was you (The Royal You) ;).

Just out of curiosity, is there anyone still managing Fossil repositories like this?

Thank you Andy for sharing. I am using this approach to track differences between Application on DEV/ACC and PRO servers since February 2015.

On each server, there are several repos (tracking important sub-directories), all repos from all servers are synced into one "merged" repository. It provides invaluable views into differences between environments.

I wish, I could "open" repo in a root directory of server (I have read rights only, no way to have write there) without need to place .fossil there.

On the down side I see no friendly/local way to decompose/simplify merged repo into some meaningful slice (except heavy artifact shunning or privacy evading GitHub involving process by Offray)

Fossil is capable of handling multiple DAGs in a single Fossil repository, but you have to take care to keep the names of your branches unique in the different timelines or you'll end up with spurious warnings about forks. For some interesting reading on the topic, see 1, 2, and 3.

These messages all mention the use of shunning and SQL trickery, but that’s not even necessary nowadays. I currently have several repositories containing multiple completely disconnected branches, that have no overlap whatsoever; simply by using fossil open --empty, and specifying a new branch on the first commit from that checkout.

Just out of curiosity, is there anyone still managing Fossil repositories like this?

I’ve been using the principle for several different reasons. (I’m not saying they are good reasons. Those were just the reasons I started using that methodology; they seemed good, or even just interesting, at the time):

• The source code in trunk, and the release binaries in a ‘disconnected’ release branch. Fossil’s /zip URL allows me to easily publish links to either the latest release (fossil.example.com/zip/latest.zip?uuid=release), or (by using version tags) to specific releases. Works a treat!
• Multiple attempts at making a certain tool, in completely different languages and toolsets. They have nothing in common but the end goal, so the notes containing the requirements (wiki etc.) are shared across the board. Since the different attempts are written for completely different languages and environments, no merging would ever happen between the disparate branches.
• Multiple aspects of the same piece of software that run in different environments, like a collection of scripts, located on different servers, yet working together). It’s very handy to be able to checkout a branch on each server without getting the cruft destined for the other servers; yet all the information is located in the same repository.

The one ‘disadvantage’ of doing this, is that all these branches, disconnected though they are, all show up on the same timeline. Of course, it’s possible to limit the timeline to a specific branch, but usually, I want to see the splitting and merging branches as well, and those then get snipped as well.

So they’re not completely independent. Of course, they also share all tickets and wiki pages.

The one ‘disadvantage’ of doing this, is that all these branches, disconnected though they are, all show up on the same timeline.

The d=CHECKINORTAG query parameter to /timeline will show the descendants of the specified check-in. If you give the original check-in of a branch, you will see just check-ins for that branch and its subbranches.