I'm trying to understand the guiding principles behind why certain features are available in Fossil and others aren't. I've used version control for a long time, since rcs (anyone remember this???) through cvs, svc, etc ... and then settled on git simply because of network externalities. I want to like Fossil, and I've tried to use it before, but I just don't "get" it.

For example, UNX advocates simple, short, modular, which Fossil clearly isn't it. It has an embedded web server, wiki, ticketing. It has chat (!?) Some of these just arguably aren't version control type features.

So we accept the monolithic design, and say "let's put in everything that, when you do version control-ish things, you might want". If so, then why can you not look at your working directory and see what files have changed, what the diffs are, and select files to commit?

Please explain.

Hello,

I'm trying to understand the guiding principles behind why certain features are available in Fossil and others aren't.

The features that are available in Fossil is because someone put them in and drh didn't have objections to it. The unknown things you're referencing are not in Fossil because someone has submitted a patch or code to add them in. It's possible that did happen but there were objections to it. You would need to be specific about what feature you're talking about.

Some of these just arguably aren't version control type features.

github/gitlab have the features you mentioned.

then why can you not look at your working directory and see what files have changed, what the diffs are, and select files to commit?

One small example of how this is possible: https://marketplace.visualstudio.com/items?itemName=koog1000.fossil

I am not going to go into an in-depth explanation here, but I think that you have expressed some misconceptions which contribute to your not getting it.

Even the (once) beloved RCS was a suite of small, narrow purpose tools. (It still is and I still use it for /etc/ content.)

Your definition of modularity may be narrower than what is needed to grok the virtue of functional separation and well defined interfaces. Just because the modules are not designed to be conveniently replaced does not mean they are not there. (Think of a car's engine.)

There is much more to modern VCS, and more so to DVCS, than seeing what files have changed and what diffs they have relative to something checked in.

Selecting files to commit rather than treating changed files as a unit went out of style years ago, for good reason. Changes work together, as a rule. So, as a rule, Fossil makes controlled file change sets easy to deal with and allows individual per-file manipulations with some extra specification.

Having a set of tools that must work together ship together is a great convenience. Lack of an installer or need for one is a virtue. As you say, Fossil is like a bag of tools with strings tying them to the bag. (If you have children old enough to borrow tools, you might like those strings.)

As for the precise selection of features, when Richard Hipp created Fossil, it was to solve problems he viewed as not well addressed by more easily obtained tools. Since then, Fossil has evolved with developer's utility and convenience high in the priority list.

You may be aware that bug tracking, documentation, project write-ups, and code are ordinarily connected in larger organizations. The connections are sometimes only by non-enforced linking conventions. Fancy commercial systems provide good, reliable linkage. Fossil does too, when users choose.

I would urge you to consider how a set of distinct tools that all had to play together would really work if they were not tied together. What if RCS file formats had to evolve? Would you not want a migrator and a new set of co, ci, rcs, etc. that all understood the new format and what to do if the older one was encountered?

Finally, you pay very little for the features you do not use. That is true in disk space, memory, CPU cycles and, of course, money. So I advise not fretting over the utility you do not (yet) find use for.

BTW, I too worry about endless feature and mission growth. But I look at the situation pragmatically rather than lamenting absence of a more modular approach.

I'm trying to understand the guiding principles

Fossil was originally founded to become the source management system for the sqlite project. That was its sole purpose in life, and that defined the scope of the project and the initial list of features.

At the time (mid-2007) sqlite used CVSTrac, and Richard (founder of both fossil and sqlite) wanted similar features. Rather than develop a series of disparate components, he chose, in the interest of expedience, to develop a monolithic app framework which, in the long run, would speed up and simplify development compared the use of library-style APIs. (For example, fossil installs a memory allocator which crashes the app if it runs out of memory, which means that the developers are spared tons of error checking because they know that certain operations simply cannot fail without crashing the app.)

Though i'm fundamentally a library-level developer at heart, working on fossil's internals is a breath of fresh air at times because it allows a developer to ignore certain tedious aspects of working with libraries.

If so, then why can you not look at your working directory and see what files have changed, what the diffs are, and select files to commit?

Features which interact with a checkout via the web-based UI are far more difficult to implement than those features which deal with the repository state. The former requires lots of filesystem-level manipulation and the latter requires working only with a single database connection. The former also has security implications which the latter lacks. Any filesystem-level access via web apps has security implications, but the latter has only a single point of filesystem access, not an arbitrary number of them like a checkout does. The HTML UI offers only a tiny handful of features which access a local checkout.

Error recovery from, say, a failed sync during a checkin or a failed merge, would be difficult to do well in the HTML interface. Those are far better left to the CLI.

The UI is intended primarily for remote access of hosted repositories (as opposed to checkouts) and the CLI for local access to both repositories and checkouts. Some few operations, e.g. moving a checkin to a new branch, call for the UI even for local checkouts, but there aren't many such operations.

For example, UNX advocates simple, short, modular

1. That's a nonsense myth. Early unix programs were simple and small because they ran on machines with very limited memory (ex: 24KB) and so had to be small in order to fit in core. There is nothing virtuous about requiring 150 small, independent programs that the operator tediously strings together to accomplish some task. The goal of Fossil is to be "simple". Being a single self-contained binary as part of that goal. No installer is required. There are no (or at least very few) dependencies. No fussing around with shared libraries or DLLs or registry settings or plist files is required. There are no /etc/fossil, /usr/shared/fossil, /usr/lib/fossil, or /var/fossil directories to create, manage, or understand. You simply put the stand-alone binary someplace on your $PATH and it works. To uninstall, delete the binary. To upgrade (or downgrade) just overwrite the binary with a different one. Simple. Easy. Direct. Is there any other version control system (current or historical) that is so simple to manage?

2. Fossil is not a UNX program. It is cross-platform. Though I primarily work on Linux (as it has the best desktop), I also work on Win10 and MacOS. Fossil runs natively on all of these, without requiring mingw or mtools or cygwin.

3. Fossil is not a "version control system". It is a software management system, including tools for managing the entire software development process. Version control is part of that process, but so is bug tracking, and wiki, and chat, and this forum.

If so, then why can you not look at your working directory and see what files have changed, what the diffs are, and select files to commit?

Who told you that you couldn't do those things? Those are core commands that are used by me (and thousands of other Fossil users) every day:

• fossil changes
• fossil diff ?FILE? ?FILE? ...
• fossil commit FILE1 FILE2 ...

Have you been reading disinformation published by Git partisans?

Thanks everyone for your replies.

I have indeed read a lot of (dis)info published for both Git and Fossil. I don't necessarily believe that simple/short/module is myth. Most new tools I see still conform to a the "single purpose" paradigm.

I'm also not talking about implementation simplicity. There is nothing to prevent someone from releasing a single executable, no dependencies version of Git that does 90% of what most need. It's been done. Just that the implementation hasn't seen wide acceptance.

I'm talking about how features are decided for inclusion/exclusion. If Fossil follows the monolithic principle, why does Fossil, for example, have no browser-based support for most daily VCS activities such as committing, branching, merging, etc., but does have extensive browser support for tools surrounding source code management like a forum and chat?

I have a guess. Perhaps the authors consider things like committing and branching a command line activity and forums and chat a browser activity? Just looking to understand the guiding principles, as I said.

I don't necessarily believe that simple/short/module is myth. Most new tools I see still conform to a the "single purpose" paradigm.

First, there is a single purpose, albeit a grand one. As Richard said, its purpose is software management.

If you are fond of less grand purposes, you can easily write some aliases, each of which invokes fossil with one of its subcommands. (My 'foh' alias does that, invoking the help subcommand.) You could go to town that way, obtaining the aforementioned packaging advantage yet reaching the "single" purpose user's view of the tool(s). Of course, you will probably want to expand each subcommand according to its useful option combinations. (Have fun with that!) An example of this approach is a tool (set) called busybox, something very popular in embedded systems work for the same reasons that Fossil's packaging is seen by others as an advantage.

If Fossil follows the monolithic principle, why does Fossil, for example, have no browser-based support for most daily VCS activities such as committing, branching, merging, etc., but does have extensive browser support for tools surrounding source code management like a forum and chat?

Fossil has browser-UI mainly for viewing the repo with views conveying various useful information subsets, but few for altering repo state. (And those few effect minor alterations rather than the major alterations done from a CLI shell.) This follows workflow convenience for people who do not use some other grand tool to do "everything". (Some IDEs, for example.)

I have a guess. Perhaps the authors consider things like committing and branching a command line activity and forums and chat a browser activity?

A good guess. Another activity for which the browser-UI is great is trying to understand the version DAG and viewing file differences among its node pairs. The same information is available via the Fossil CLI, but I think you will agree that the graphical presentation and node selection feature is much quicker and intuitive to use than the CLI equivalent.

I have a guess. Perhaps the authors consider things like committing and branching a command line activity and forums and chat a browser activity?

Exactly. If someday I decide that committing from a browser is useful, I'll likely implement that capability. (Adding new commands and/or webpages to Fossil is very simple. The new commands are largely isolated from the others, so the new feature is low-risk and easy to debug.)

As it happens, I don't have a use-case for commit-from-browser, nor is there sufficient commotion from the broader users community for such a thing. So it has never been implemented.

Features are added as needs arise.

Fossil recently added support for chat. This happened because Big Sur came out with greatly reduced support for Tcl/Tk, and so the Tcl/Tk based chatroom that the SQLite developers had been using for 20 years became harder to support. The older Tcl/Tk chatroom was long in need of an upgrade (for things like encryption and persistence of messages) so rather than fixing Tcl/Tk on Mac, I decided to redo the whole thing in Fossil. The change has worked well, so far. There was a need. Fossil was enhanced to meet that need.

Fossil picked up the "Forum" capability several years ago, in response to inadequacies in MailMan and in the general internet email infrastructure. Spam control is much much easier with Forum than it ever was with MailMan. Plus, with Forum, we can format messages in Markdown, and use "fossil sync" to backup all historical conversations. It was a big win, and now Forum has replaced legacy mailing lists. There was a need. Fossil was enhanced to meet that need.

Do you see the pattern?

Fossil was invented for one purpose: to support the development of SQLite. It has since been adopted for use on many other projects as well, which is great, as that makes Fossil a better tool for use by SQLite. But its original purpose is still there - to support SQLite development. When inefficiencies are identified in the SQLite development processes, my first thoughts are how can Fossil be enhanced to address those deficiencies.

Just that the implementation hasn't seen wide acceptance.

That's never been an explicit goal of this project. Those who use it, use it. Those who don't, don't. It's not a popularity contest.

I'm talking about how features are decided for inclusion/exclusion.

Someone gets an itch for a feature and they implement it. With very few exceptions, it's then added to fossil. "It's 100% organic."

If Fossil follows the monolithic principle, why does Fossil, for example, have no browser-based support for most daily VCS activities such as committing, branching, merging, etc., but does have extensive browser support for tools surrounding source code management like a forum and chat?

i answered that in my first response. "Most daily VCS activities" require a checkout, wheres, e.g., forum and chat do not. Working with checkout-level state from the browser has a variety of pitfalls, not the least of which is security implications which simply don't apply when talking to a repository database.

Just looking to understand the guiding principles, as I said.

1. Someone gets an itch for a feature.
2. They implement it. (As often as not, they first ask about potential interest on the forum, to avoid implementing something which the project ultimately won't accept.)
3. If it's not totally "against the grain" or way out of scope, it's generally accepted.

"It's 100% organic."

I have a guess. Perhaps the authors consider things like committing and branching a command line activity and forums and chat a browser activity?

Nobody here wants to edit forum posts from the CLI, nor maintain a UI for such a tool (which would require 3rd-party code dependencies for the UI bits unless it were 100% 70s-style menu-driven). Similarly, the chat's server-side implementation assumes HTML text, which would effectively lead to screen garbage in a CLI tool. You can send messages to chat via the chat CLI command. You can, if you really want to, read them using the sql command, but nobody here has been bothered enough by the lack of a fully-interactive chat CLI interface to implement it (noting that they would have to implement the networking aspects, including all I/O and recovery from broken connections, on their own, whereas the HTML-based client lets JavaScript do all of that in a trivial amount of code).

The process is - you guessed it - 100% organic. Someone needs/really wants it, then that someone writes it or convinces someone else to do so.

I sent Richard a couple of (admittedly somewhat lengthy) emails

That was your first mistake. :)

drh is a busy guy. You'd have been better off announcing it on the forum, where you can find champions for the feature, who can then help you convince drh to get it merged down to trunk.

the etiquette about "announcing it" on the forum

I'm not sure there is an etiquette about that. I mean, the forum's pretty free-wheeling as long as you're not breaking any rules. The worst I can imagine happening from a blind announcement to the forum about a new branch is simply that it gets ignored. (Ask me how I know. 😉)

that branch should still work

It seems to, but let's take this up on a new thread I've started. This thread is about other things.

As far as this thread goes, it suffices to point out that itches do sometimes get scratched, though they don't always make it to trunk. We'll see about fixing that via the other thread, okay?

Yes, I realise now that just posting on the forum would have been the best, but at the time I didn't know that I wouldn't be stepping on any toes by making a blind announcement so I (probably foolishly) didn't :-)

I've made a first response to your other thread: once I've refreshed my memory of what I did in the morning, and I've hopefully tried your update-from-trunk merge, I'll probably add more tomorrow.

but at the time I didn't know that I wouldn't be stepping on any toes by making a blind announcement

We thankfully have a distinct shortage of sensitive toes here :).

The anonymous OP of this thread is very concerned with "guiding principles". To the OP's credit, I suppose it is important to think about guiding principles. Certainly Fossil has guiding principles - all projects do. The question is whether or not those guiding principles are well articulated. To that end, I will make at attempt at listing a few of the important guiding principles of Fossil. Understand that this post is a work-in-progress draft and is not authoritative. Do not hesitate to offer enhancements and/or corrections.

Enduring

Content stored in Fossil should be accessible and usable to developers who have not yet been born. It needs to support SQLite until at least the year 2050, and probably beyond that. The underlying file formats must be simple, carefully designed, and well documented.

Honest, Auditable History

Fossil puts emphasis on recording what actually happened, and de-emphasizes keeping a "clean history". Telling the truth is more important than telling a good story or a simple story.

Code provenance must be unimpeachable.

High Visibility, Transparency, and Situational Awareness

Participants in projects hosted on Fossil should have no difficulty keeping up with what is happening in the project. Miscreants should not be able to surreptitiously insert malicious content.

The timeline, and the "Security Audit" pages are prime examples of this principle in operation, though the idea of recording the true history of changes and making information available in as many forms as possible permeates the project.

Low Administrative Overhead

Fossil should be easy to set up, operate, and maintain, both on the client side and the server side. The job of the developers is to work on their projects, not to administer the version control system. Fossil should do its job and otherwise stay out of the way.

The single-file executable design supports this goal.

Low Dependency - Flexible Deployment - Cross Platform

Fossil should run on any modern desktop or server OS. It should not require auxiliary software or libraries or sub-components.

For example, on the server side, Fossil works with Nginx, Apache, or any other web-server that supports CGI or SCGI, or it can run with no web-server at all using its own built-in web-server implementation. As a single-file executable, Fossil is able to run inside of chroot jails or other security enclosures.

Communication is by standard protocols: HTTPS and SSH. No custom TCP ports or firewall rules required.

Low Cognitive Load

Fossil should "just work". Operators should not have to stop and think about what they are doing. Everyone has a finite number of "brain cycles". The more of those cycles that are expended figuring out the version control system, the fewer are left over to solve actual customer problems. To this end, Fossil should be as simple to operate as possible.

Low Overhead

Fossil runs on low-power machines - shared hosts, $5/month VPSes, or Raspberry PIs sitting in the corner of the local network. The less horsepower needed to run Fossil, the more likely it is to be run and to be mirrored, thus increasing the survivability of the projects it is hosting.

Organic

Fossil is written by the developers who actually use it in their day to day work. The feature set meets real-world needs.

For example, on the server side, Fossil works with Nginx, Apache, or any other web-server that supports CGI or SCGI, or it can run with no web-server at all using its own built-in web-server implementation.

#Is built-in web server = 'fossil ui' or did I miss a new feature?!

built-in web server = 'fossil ui' or did I miss a new feature?!

The ui command is a convenience form of the server command. The latter starts an HTTP server process and the former does that, then launches a browser pointing at that server. There are minor differences regarding their defaults for how they handle authentication (auto-login via ui and not (by default) for server), but that can all be tweaked via flags.

Thanks for this. I think that this guiding principles should occupy a more prominent role in the documentation as they are important as a base for getting a panoramic overview of a project (I tend to read it wherever they are stated).

Thank you for this. It or something like it should be promoted to the main docs. I would also include this bit below that I copied from a previous post in this thread. It very nicely and succintly re-oriented me to what Fossil's frame actually is relative to Git, Mercurial, and friends.

Fossil is not a "version control system". It is a software management system, including tools for managing the entire software development process. Version control is part of that process, but so is bug tracking, and wiki, and chat, and this forum.