I've changed the way "fossil server --chroot" interacts with the single-repository case, which solves my use case, but I'd like anyone using this flag to ensure that it doesn't accidentally break your use case.

The simplest way to demonstrate my motivation for changing the behavior is this test case:

  $ fossil server --chroot ~/tmp ~/tmp/museum/repo.fossil

This works as expected: it does a chdir into ~/tmp and serves up the named repo.

The problem is, running the same command under sudo used to fail because that sent it down a code path that not only triggered the chroot(2) call, it then tried to open "/" as a repository name! Needless to say, this failed, resulting in a "Not Found" error when you tried to view the web UI for that repository.

I believe that was done to cater to --repolist mode, so what I did was check that there's a Fossil repository already given by that point, and if so, check whether it's underneath the jail directory. In that case, I return the "jailed" version of the repo path name ("/museum/repo.fossil" in the example above) so it will open correctly inside the jail.

The motivation for all of this is improvement to the stock Docker container, which will allow it to be more practical, serving its repository from a mounted volume, rather than from inside the container. However, this should have practical use on bare metal as well.