Since sqlite (fossil databases are such) abstracts the filesystem, can a fossil repository, alas sqlite database be created based on a list of files, regardless their location on the file system, as such, do away with the notion of a checkout directory,

The short answer is no. The restriction of "has a checkout directory" is very much baked in to fossil and is fundamental to many of its algorithms.

Allowing fossil to operate outside of a given checkout is inherently a major, and very real (not academic or hypothetical), security risk. If you were to open such a repository from some complete stranger, it might overwrite your /etc/hosts, your ~/.bashrc, or any other file.

That would be an elegant addition to the binary?

Perhaps to a binary, but not to fossil's binary (IMO). SCMs are designed to house individual projects, by and large source code, and not arbitrary files from arbitrary places in a single repository which spans a whole root filesystem. We cannot escape the "mental construct" of a filesystem so long as fossil lives within one and serves from housed in one.

No more than is posed by /fileedit, which as far as I'm aware, is as strong security-wise as Fossil generally: its RBAC, its SQL verifier, the new DB read-only locking feature… That in turn is all protected by your local TLS setup, plus things like chroot, containers, etc.

The risk inherently posed by /fileedit is limited to a single checkout, however. Do away with a checkout, such that a single repo can manage anything across a system, and the risk explodes into arbitrary directories. The sandbox of a checkout is as much a security abstraction as it is an organizational one.

(Pardon my brevity and likely lack of future responses - finalizing packing up for a move in the morning.)

If the OP wants Fossil as the root filesystem, I'd say the lack of file permissions is a bigger problem than any of that.

The filesystem should be able to take care of versioning, backup, "snapshots".

Many do, and some have for decades. The premier modern example is ZFS, coupled with its send/recv features, now cloned by btrfs.

There's also APFS + Time Machine in the Apple world, ReFS + VSS in the Microsoft world, etc.

The main thing you lack in these relative to Fossil is a commit commenting mechanism. Some of them allow a hierarchy of versions, etc.

eliminate the higher constructs and "frame-works" ad infinitum

What is Fossil in this context but another framework, an abstraction of filesystem contexts?

SQLite is on the same order of complexity as a filesystem, which you want to replace.

What've you bought?

A relationship of Gigabytes of software to a few Megabytes of content (more often Kilobytes) is preposterous.

The tradeoff is faster development time, without which you wouldn't have as much useful software as you do, including Fossil, which depends on:

• A whole pile of development tools (compilers, editors, build tools, a Tcl interpreter…)
• The browser's JS interpreter and HTML layout engine at runtime
• And at both development and runtime, much of the OS comprising those gigabytes

If you look at Fossil as a 4-6 MiB executable while ignoring all that, I wonder how much you think Fossil should adopt into its core. The plan is beginning to look distinctly inelegant.

markup that can be ignored by the machine is often a step foreward

I'll agree with you this far. I've stopped using word processors, for the most part. When I need to produce PDFs or paper documents beyond the capability of Markdown and a sensible rendering engine + style sheet, I jump to page layout software.

html&scripting is such a layer of complexity

Can we infer from this that you don't find /fileedit or the linked VSCode Online options appealing?

If not them, then what do you propose? A Vim plugin that edits files from the repo instead?

open up the database, ...and butt upon a file structure.

I'm not parsing your English well, but if I understand it, I want you to contemplate this: what is a filesystem if not a hierarchical database indexed by paths?

Not the case to my knowledge in any os/filesystem?!

HFS had resource forks for metadata like this in 1985, since added to many other filesystems, and Linux extended attributes allow 4 to 64 kiB of data per attribute, depending on the actual FS in use. That's plenty for a checkin comment.

In the case of Fossil, as is, there is the checkout

You started this thread wanting to get away from checkouts. So, how do you expect to edit a file, exactly?

certain files in /etc

Simple answer, then: don't. Fossil doesn't track file permissions.

You can find this asked and answered multiple times in the archives here.

There are other tools that do this properly.

You can remove all your checkouts and have such a database.

The trick is, what can you do with it now that you have it, without creating a new checkout?

Most of the Fossil functionality can be done through the web UI, one way or another, including file editing thanks to Stephan's /fileedit feature. It's useful, but IMO it's more an emergency or contingent-use feature, not something you want to use every day. Even 1979 vi is a more capable text editor than what you get with browser <textarea> tags.

The bigger DVCSes have features like github.dev to strap a better editor onto their web UI, but the Fossil project doesn't have GitHub's staff to do such integrations. We have volunteers, but are you the one who's going to do this for Fossil? If not you, then who, and why?

Inversely, there are independent web-based editors like vscode.dev that know how to reach out and edit files on a remote repo without cloning it, but I don't know how you'd get them to add Fossil support. There's a VSCode Fossil plugin, but I doubt that helps here. It probably requires someone from Microsoft to do the low-level integration. How do you get them to do that when they're all-in on Git these days?

That aside, these mechanisms aren't "elegant additions to the binary." They're external integrations that make use of the back-end DVCS's existing capabilities. Fossil should be able to do the same, at least in principle, but the hard work needed to do it isn't in the Fossil binary.

The bigger DVCSes have features like github.dev to strap a better editor onto their web UI, but the Fossil project doesn't have GitHub's staff to do such integrations. We have volunteers, but are you the one who's going to do this for Fossil?

Little-known trivia, though: there is a hook in place to replace the admittedly horrid /fileedit and /wikiedit editor widget with one's own. It would have to be loaded via the site skin, and it's never been done "outside of the lab," but we do have a hook in place for it:

src:/doc/trunk/www/fileedit-page.md#editor

Even so, repository still has a virtual root directory which becomes the root of any checkout, so a user cannot completely eliminate the idea of "some top-level directory" in fossil. Whether that top is a repository root or checkout root is arguably irrelevant, as a checkout is effectively just a different representation of a repository's root.

If I were you I would play with fuse(4)