So, I want to offer version control in my own commercial application as a feature. Can fossil be used for this...

Fossil is a "monolithic application" which does not lend itself well to embedding in another application. We make no guarantees about the format of its output, making it "unstable" from a scriptability perspective. It's simply not that type of software. It's an interactive tool for human software developers, and any other uses are of secondary/tertiary/etc. concern in its development.

libfossil, a pseudo-third-party effort, does lend itself to embedding fossil-compatible features into applications, but it's a library (as opposed to an application), completely devoid of any UI components - applications have to provide all of those themselves. It also doesn't have any direct networking support, so it relies on the main fossil binary to do that part of its work. (We're still waiting on an avid volunteer to port fossil's sync layer over to a library-style API!)

and would the license allow it?

Absolutely. There are no onerous limitations in fossil's "BSD-style" license. libfossil uses the same license.

Hi Stephan,

Thanks for the info and the quick reply.

I was thinking of running fossil as an external binary no embedded in my app and then catch the output or collect changes.

I was planning of looking at the code of this project https://fuel-scm.org/fossil/home to see how it gets info from fossil.

Or, embed the fossil's web interface in my app? and customise the css? not sure if it is possible though

Thanks,

John

I was planning of looking at the code of ... to see how it gets info from fossil.

The only approach there is is to parse fossil's output, but that's very fragile. Though we make some effort to not outright break scriptability of certain commands, we aren't tremendous sticklers about that sort of compatibility because fossil is, first and foremost, an interactive tool.

However, with libfossil you can write small custom applications (or features in your own application) which, e.g., fetch info from a fossil repo and format it however you like. For example:

https://fossil.wanderinghorse.net/r/libfossil/file/f-apps/f-ls.c

provides a feature equivalent to fossil's ls command, just in a different format. Similarly:

https://fossil.wanderinghorse.net/r/libfossil/file/f-apps/f-timeline.c

provides a feature similar to fossil's timeline command.

Though those are standalone applications, the same features/code can be copy/pasted into client applications and reformatted to suit.

Or, embed the fossil's web interface in my app? and customise the css? not sure if it is possible though

i don't believe that the embedding part is feasible, but would love to be proven wrong.

What is at least conceivable, though, is to fork fossil and add pages for your own features, removing any of fossil's pages which you don't want. It would have significant limitations (e.g. fossil's /path routing only supports a single top-level /path, so /foo and /foo/bar/baz both refer to the same page handler), and it would require getting very comfortable with fossil, but it's at least a somewhat conceivable approach.

Another feasible option (depending on what features you'd need access to) for working directly with a fossil binary via "remote control" or embedding is to make use of the JSON API.

The only approach there is is to parse fossil's output, but that's very fragile

Could the Fossil's JSON commands be used to have a relatively predictable output? Or there is too much missing for it to be feasible?

Could the Fossil's JSON commands be used to have a relatively predictable output?

If the subset of features is limited, absolutely, but there's plenty of stuff that API won't do, like checking in new non-wiki content.

I want to offer version control in my own commercial application as a feature.

I'm a bit sorry to sort of playing the devil's advocate here, but if you ostensibly do not intend to use "the interactive" part of a VCS system¹ then why not just pick Git? It is specifically designed to have two layers — the set of low-level commands intended for calling by other commands, including yours, and the set of higher-level commands intended to be used by humans; the output of the former set of commands is machine-parsing-friendly and never changes (and is being tested to not change inadvertently).

Another approach would be using libgit2 or any other similar 3rd-party library, which are many.

Git comes under the terms of the GPL but you're not going to create a "derived work" based on it, so it would suffice to mention its license in the about box/docs (with the link to its landing web page/Github repo).

---

¹ Elsewhere in this thread you consider using the Fossil's web UI but I fail to see how one could easily embed that into a foreign app: implementing something as a feature presupposes tight and seamless intergation, and merely displaying an UI of an external tool does not fares as one.

Git requires a system-wide installation with admin rights whereas fossil does not or, have I got this wrong?

In any case, my app is not about developers so I don't see why the end user should install git on their pc.

Git requires a system-wide installation with admin rights

Git can, if one builds it from sources, configure it to live in their own home directory, running as their own user.

Conventionally, it's installed globally, though. Perhaps (i am uncertain) it needs admin rights on Windows, but it does not require root access on any Unix-like OS.

whereas fossil does not or

Fossil is commonly installed in a single user's home directory. Literally none of the systems i administer have it installed globally.

Thanks Stephan. I will have a look at the lib and JSON, which at a first glance looks very promising.

Picking on something that came up in another reply, does fossil require admin rights to run?

Linking against GPLed libraries is, indeed a PITA but libgit2 (to which this applies) works around it by providing a linking exception in its license excplicitly — to cite its README:

libgit2 is licensed under a very permissive license (GPLv2 with a special Linking Exception). This means that you can link against the library with any kind of software without making that software fall under the GPL.

So, basically, you cannot fork that lib and publish its code under something non-GPL (v2 or above) but are fine to link against it.

does fossil require admin rights to run?

The only two cases where fossil needs any admin rights are:

• When it is run in standalone server mode and must open "privileged" network ports (e.g. ports 80 or 443).

• When run in standalone server mode (regardless of the port range) and it is told to read a private system-level SSL certificate (via fossil server --cert /some/file), as reading such a certificate requires elevated privileges.

When running "as root" ("admin" in Windows terminology) fossil will drop its root privileges at the earliest opportunity (after it's opened a privileged port and/or read the privileged cert file). See src:/doc/trunk/www/chroot.md for more details.

There may be a bit of misconception going on, so I'm going to clear things up a little.

There is Git which is a piece of software and there is Git which is packaged in a particular way to be installed in a particular system. The former is delivered in the form of a software repository and "tarballs" with the released versions of the software. The latter is done fore the end users.

(A side note. Actually all the same things apply equally to Fossil but one of the strongest Fossil's selling points is that it comes in the form of a single file eligible to so-called "xcopy deployment". Then again, the compiled form of Git can be distributed in mostly the same way, just it would consist of a whole lot of files, not just a single one (also see below).)

OK, so as Stephan correctly pointed out, the "official" installer provided by the folks behind the Git for Windows project can be used to install for a non-admin user. The same project also provides the so-called "portable Git" which is basically the "unpack and use" thing.

I should possibly note again, that "pure external" implementations do exist, which are compatible with the Git's repository format(s) — libgit2, JGit, LibGit2Sharp are these (among others). They do not require Git to be installed in the system.

Fossil is commonly installed in a single user's home directory. Literally none of the systems i administer have it installed globally.

Interesting. So you skip the make install step and just copy to something like /home/stephan/bin/?

So you skip the make install step and just copy to something like /home/stephan/bin/?

To ~/bin/fossil.bin, and ~/bin/fossil is a shell script which first looks for a fossil binary in my local checkout of this project. If one exists, it runs that one, else it runs ~/bin/fossil.bin. The reason for that is because i normally want to run whatever is in the checkout, but i still need to be able to use fossil when my local checkout is in a non-compilable state or is in the process of compiling during a clean rebuild. History has taught me that i always need a working fallback binary, and that one is ~/bin/fossil.bin.

Edit (again, this time to make it more portable to BSD machines):

$ cat ~/bin/fossil
#!/usr/bin/env sh
# Looks for a fossil binary in various places and executes the
# first one it finds.
cd > /dev/null
home=$PWD
cd - > /dev/null
froot="$home/fossil"
for x in "$froot/fossil/fossil" \
         "$home/bin/fossil.bin"
do
    if [ -x "$x" ]; then
        exec "$x" "$@"
    fi
done
echo "No fossil binary found." 1>&2
exit 127

I was wondering if fossil supported JSON on the CLI but I couldn't find a page for fossil json here. Eventually I found documentation here.

I was wondering if fossil supported JSON on the CLI

Yes, it does.

... but I couldn't find a page for fossil json here.

Fossil's help command/page can only show help for commands which that specific fossil binary knows about, and the json command is not compiled in by default. To enable it in a local checkout:

$ ./configure --json

Eventually I found documentation here.

Alternatively:

• Go to fossil's main home page
• Click on the "Doc Index" in the box on the right-hand side of the page.
• Ctrl-F and search that page for "json". Note that the entries under "Other Documents" are in alphabetical order, so you can also just scroll down to find it between the "I" and "L" entries.