[fossil-users] remote check in

[Scott Doctor]

I am trying to figure out how to use fossil for an upcoming
project. I keep coming back to fossil as the alternatives (git,
mercurial,...) are just... well I will go bald trying to figure
them out. I made a test repository to play with and mostly
figured out the command line commands. The problem I am having
is how to add files, do check-ins and such via the UI, mostly
regarding doing it remotely without command line access.

My question is, for example the sqlite fossil system, someone
wants to check-in a change of a file, or add a new file. How do
they do such over the internet without having command line
access? I do not see any operations from the UI that does that.
Seems adding files, doing check-ins, merges, should all be part
of the UI. So do people who have a check-in or a new file email
the file to the administrator and they add/check-in, or do those
people have command line access?

[K. Fossil user]

Hi,

« So do people who have a check-in or a new file email

the file to the administrator and they add/check-in, or do those
people have command line access? »

1/ People don't really use Fossil : they do use git/mercurial/etc.
2/ Those who use Fossil use command line most of them.
3/ The purpose of SSH (long talk with the Fossil users) is to help people use secure remote command line...
(This is how I understand it)
4/ I was wondering if Fossil have got something that is not "command line". I dunno.


Best Regards

K.



De : Scott Doctor <***@scottdoctor.com>
À : Fossil SCM user's discussion <fossil-***@lists.fossil-scm.org>
Envoyé le : Samedi 22 octobre 2016 22h40
Objet : [fossil-users] remote check in

I am trying to figure out how to use fossil for an upcoming
project. I keep coming back to fossil as the alternatives (git,
mercurial,...) are just... well I will go bald trying to figure
them out. I made a test repository to play with and mostly
figured out the command line commands. The problem I am having
is how to add files, do check-ins and such via the UI, mostly
regarding doing it remotely without command line access.

My question is, for example the sqlite fossil system, someone
wants to check-in a change of a file, or add a new file. How do
they do such over the internet without having command line
access? I do not see any operations from the UI that does that.
Seems adding files, doing check-ins, merges, should all be part
of the UI. So do people who have a check-in or a new file email
the file to the administrator and they add/check-in, or do those
people have command line access?

[Shal Farley]

K,

It would be helpful to the other members of this list if you would not
chime in with provocative non-sequiturs when you don't know the answer.

Just my humble opinion.

Shal
(see, you trolled me out of my lurking state)
--
Shal Farley
Cheshire Engineering Corporation
http://www.CheshireEng.com

Post by K. Fossil user
Hi,
1/ People don't really use Fossil : they do use git/mercurial/etc.
2/ Those who use Fossil use command line most of them.
...

[K. Fossil user]

Hi,

« It would be helpful to the other members of this list if you would not chime in with provocative non-sequiturs when you don't know the answer »

a) non-sequiturs ? Where ?
b) I try to answer if I've got an opinion.
I don't answer everything, I don't even read everything even if it is an answer of what I've asked.

What I would like to say when I gave my first comment in this thread :I was wondering if it is possible to do EVERYTHING [Fossil related of course] in a browser.I guess in theory it should be, but in practice? In the past, I was explained something (I don't remember what exactly it was but I would like most of the time that a command line result could be seen in a browser) that was not easy as one two three.

And I was told in the past, that one could use a browser to throw a command line (BASH ?) to a remote server.It is something I won't recommend, but when I've read your statement, then I suppose that I should give that info to you...(I am not responsible [...] harm your computer [etc.])

« Just my humble opinion »We respect people opinion even if we don't like them.
« People don't really use Fossil : they do use git/mercurial/etc »

Is that untrue ? Nope.

« Those who use Fossil use command line most of them. »

Is that untrue ? Nope.
NB: Command line is better for scripting.


Best Regards

K.
De : Shal Farley <***@CheshireEng.com>

*snip* (sorry some part of the mail [beginning] is deleted)




K,

It would be helpful to the other members of this list if you would notchime in with provocative non-sequiturs when you don't know the answer.

Just my humble opinion.

Shal
(see, you trolled me out of my lurking state)
--
Shal Farley
Cheshire Engineering Corporation
http://www.CheshireEng.com

On 10/22/2016 3:52 PM, K. Fossil user wrote:
Hi,

1/ People don't really use Fossil : they do use git/mercurial/etc.
2/ Those who use Fossil use command line most of them.
...

[Shal Farley]

Scott,

The problem I am having is how to add files, do check-ins and such via
the UI, mostly regarding doing it remotely without command line access.

I'm far from an expert user of fossil, but I believe the normal setup is
to have a local copy of the repository, where command line access is
simple and direct, and use fossil's sync feature to deliver checkins to
remote servers.

In a multi-developer situation each developer would work with their own
local repositories, in sync with a common server.

Shal

[Ross Berteig]

I am trying to figure out how to use fossil for an upcoming project. I
keep coming back to fossil as the alternatives (git, mercurial,...)
are just... well I will go bald trying to figure them out. I made a
test repository to play with and mostly figured out the command line
commands. The problem I am having is how to add files, do check-ins
and such via the UI, mostly regarding doing it remotely without
command line access.

You don't use command line access on the remote server.

For the use cases where fossil was invented, developed, and is widely
used today, you do have command line access on a local machine where you
are running your developer tools, IDE, emacs, vi, compilers, TeX, or
whatever else you need. That is usually a desktop machine of some flavor
that does provide a shell prompt. Fossil itself is broadly portable to
nearly anything with a C compiler that can compile SQLite. That
certainly includes nearly any flavor of *nix, Windows and Mac today.

On your developer PC you need a copy of the fossil executable
(fossil.exe on Windows, for example). There should be no "installation"
per se other than putting fossil in a folder where it will be found by
your shell prompt.

Working with an existing project, you would clone the public repository
to your local machine, open the clone into a workspace, work as needed
including adding, deleting and renaming files (which you do need to use
fossil commands to tell your local repository about), and finally fossil
commit the changes. Most of the time such a repository is set up
correctly to sync with the remote copy automatically, but there are
commands to manage that and manually push and pull changes as well.

It is the fossil sync command (which is an automatic part of commit)
which actually reaches out over the internet to discover remote changes
to pull and local changes to push. Push and pull command that only move
changes one direction or the other are available, but rarely needed in
my experience.

The commands listed by "fossil help" with no options are intended to be
the subset that important to new users and daily use.

My question is, for example the sqlite fossil system, someone wants to
check-in a change of a file, or add a new file. How do they do such
over the internet without having command line access? I do not see any
operations from the UI that does that.

The short answer is that they don't do that.

There has been some discussion about supporting some changes from the
UI, where the most compelling use case is to support remote editing of
documentation. But there is a (IMHO justifiable) fear of making it too
easy to commit untested changes to code. If you need web-editable
documentation, there is the wiki feature. If you need version controlled
documentation, use .wiki or .markdown files checked in to the repository
from a command line in a clone and reach them with /doc URLs on the web.

In our best understood use cases, testing implies having developer tools
and access, and that implies having a command line from which changes to
a local clone are easily made.

Seems adding files, doing check-ins, merges, should all be part of the UI.

IMHO, no, those are things that specifically should not be done in the UI.

So do people who have a check-in or a new file email the file to the
administrator and they add/check-in, or do those people have command
line access?

Anyone can clone the official fossil repository to configure and build
their own copies. The SQLite repository is the same, anyone can clone
from it and work with its full history. In both cases, essentially the
entire server is implemented by a copy of fossil itself, with a copy of
the repository.

With commit access, you set up your clone to use a supplied username and
password for access to the remote and it all just works.

[Andy Bradford]

The problem I am having is how to add files, do check-ins and such via
the UI, mostly regarding doing it remotely without command line
access.

It isn't possible to commit files to the repository using the Fossil UI.

This is also true for svn, git, and most other repositories. There do
exist tools that wrap the commands in a UI. For example, TortoiseSVN,
TortoiseGit, etc.

I believe I have seen someone announce on this list a wrapper UI for the
Fossil commands. Maybe search the archives?

Hope this helps.

Thanks,

Andy

[Steven Gawroriski]

On 22 Oct 2016 20:48:42 -0600

Post by Andy Bradford
I believe I have seen someone announce on this list a wrapper UI for
the Fossil commands. Maybe search the archives?

I believe it is called Fuel <https://fuel-scm.org/fossil/index>, as a
pun on Fossil.

[Artur Shepilko]

It's not clear what type of project the OP is trying to setup, whether it's
a programming-related project, or general document-repo type.

From personal experience, I once was facing the same question to assess
Fossil "general" viability. For this almost abstract task, Jim Schimpf's
pdf book [http://www.fossil-scm.org/schimpf-book/home] was of great help.
It also helped to focus our intended use of Fossil with our projects.

Back then we concluded that Fossil was best fit for development-type
project, as developers had no issues with command-line interactions, and
were familiar with VCS concepts and tools. QA team could also use Fossil
tickets through web-UI. However non-developer users would be simply
unproductive trying to learn the Fossil command-line for document
management, thus we chose a different approach for the document-flow
project types.

Fast-forward to present, as mentioned before, with Fuel the document-flow
gets somewhat more office-friendly.

Additionally, with the use of plugins, the developer interaction also gets
somewhat more linear, concealing the command-line for the routine tasks.
Here are a few Fossil plugins:

- Fossil plugin for IDEA-based IDEs [
https://plugins.jetbrains.com/plugin/7479]
- Fossil plugin for Qt Creator IDE, C/C++ [
https://github.com/nomadbyte/qtcreator-plugin-fossil]

Hope this helps.

[Scott Doctor]

Post by Artur Shepilko
It's not clear what type of project the OP is trying to setup,
whether it's a programming-related project, or general
document-repo type.

I am doing research where we may do a dozen iterations a day
generating about 10-100MB of files per iteration. within a short
period of time we will have well over a terabyte of information.
My current workflow uses a database (was filemaker but switched
to sqlite a while ago) like a library card catalog with notes
and status fields. The files are a combination of analysis
code, text csv, binary, and documentation. Occasionally we find
something and want to go back to older data and re-run the
experiment with a few tweaks, or modify the analysis program. I
have information overload and finding stuff, even with it
cataloged in a database, is becoming a significant chore. So I
am trying out different techniques, such as using fossil, to
track the experiments and the large volume of information.

-------------------------
Scott Doctor
***@scottdoctor.com
-------------------------

[Adam Jensen]

Post by Artur Shepilko
It's not clear what type of project the OP is trying to setup, whether
it's a programming-related project, or general document-repo type.

I am doing research where we may do a dozen iterations a day generating
about 10-100MB of files per iteration. within a short period of time we
will have well over a terabyte of information. My current workflow uses
a database (was filemaker but switched to sqlite a while ago) like a
library card catalog with notes and status fields. The files are a
combination of analysis code, text csv, binary, and documentation.
Occasionally we find something and want to go back to older data and
re-run the experiment with a few tweaks, or modify the analysis program.
I have information overload and finding stuff, even with it cataloged in
a database, is becoming a significant chore. So I am trying out
different techniques, such as using fossil, to track the experiments and
the large volume of information.

Welcome to the party, Scott.

[My foray down that
road](http://www.mail-archive.com/fossil-***@lists.fossil-scm.org/msg23837.html)

[Artur Shepilko]

Got it. Then the question is what in your opinion consitiutes a "state" for
your project?

Say, in case of a development project it may be a buildable collection of
source-files (which may include some binary artifacts used as sources).
This "state" is then being versioned in time, and Fossil takes charge of
tracking the "state" changes.

Storing binary data in Fossil gives little utility as it's not diff'able in
a meaningful form, apart from the fact that it won't scale.

So in your case, I would try to come up with some sort of a meta-project
that __references__ sources, configuration, and output data-sets(??
SQL-queries). Then version this meta-project as it progresses through the
trials and experiments. I would keep the output artifacts stored in bulk
elsewhere (DBMS, cloud, NAS etc.)

The meta-project then becomes the entity that ties all pieces together, and
its timeline may then be branched, tagged, etc.

Additionally, if Fossil indeed has to handle it all, you may use Fossil's
wiki system (versioned) to keep these "state"-transitions/conclusions
described more in-depth.

This way Fossil will be able to tell you what has changed from one "state"
vs. another by listing the diffs of such a "meta-project".

Makes sense?

Post by Artur Shepilko
It's not clear what type of project the OP is trying to setup, whether
it's a programming-related project, or general document-repo type.
I am doing research where we may do a dozen iterations a day generating

about 10-100MB of files per iteration. within a short period of time we
will have well over a terabyte of information. My current workflow uses a
database (was filemaker but switched to sqlite a while ago) like a library
card catalog with notes and status fields. The files are a combination of
analysis code, text csv, binary, and documentation. Occasionally we find
something and want to go back to older data and re-run the experiment with
a few tweaks, or modify the analysis program. I have information overload
and finding stuff, even with it cataloged in a database, is becoming a
significant chore. So I am trying out different techniques, such as using
fossil, to track the experiments and the large volume of information.
-------------------------
Scott Doctor
-------------------------
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Ron W]

Date: 22 Oct 2016 20:48:42 -0600

The problem I am having is how to add files, do check-ins and such via
the UI, mostly regarding doing it remotely without command line
access.

There do exist tools that wrap the commands in a UI. For example,
TortoiseSVN,
TortoiseGit, etc.
I believe I have seen someone announce on this list a wrapper UI for the
Fossil commands. Maybe search the archives?

That I have heard of, https://fuel-scm.org (there were a few others, but
they are too out of date).

[Ron W]

Date: Sun, 23 Oct 2016 00:51:40 +0000 (UTC)
I was wondering if it is possible to do EVERYTHING [Fossil related of
course] in a browser.
I guess in theory it should be, but in practice?

For documentation, this could be done. Fossil does part of this. Could be
improved.

For source code, this more complicated.

Sure, you could edit your source code in a webbrowser, But what about
building it? You either have to download your source files to build them
locally, or run the build on the server. Generally, this is considered to
make it too easy to commit untested changes.

Or you can edit your sources locally, build and test, then upload your
sources through the browser.

A better approach would be to make a GUI client application for Fossil,
similar to TortoiseHg. The most successful project to do this - that I know
of - is fuel-scm.org

Alternately, some IDEs still support command line version control
"providers". At least as of 2.5 years ago, SlickEdit did. For several
years, I used Fossil through SlickEdit's GUI.

[Warren Young]

How do they do such over the internet without having command line access?

Are you actually saying that your fellow researchers don’t have access to the command line on their own workstations?

I do understand that some managed PC installations do try to turn off the local OS command terminal. An IT industry columnist I follow calls such people the Value Prevention Society, because they frequently take actions to remove the value we should expect to get from user-owned PCs over mainframes and such.

If you actually do find yourself operating in such a benighted environment, you could build a GUI wrapper program around the fossil.exe binary. I’m not talking about anything grandiose; maybe half a day of time in your favorite GUI builder. You could do this in anything from VB to Tcl/Tk to HTML Applications. You could probably even do it in FileMaker. :)

(Yes, I’m making a leap here that you’re using Windows. Organizations that allow use of other OSes generally don’t even *try* to lock their users out of the local command line.)

Seems adding files, doing check-ins, merges, should all be part of the UI.

Someone has to do it. Patches will be thoughtfully reviewed. :)

[Scott Doctor]

Just to clear up some confusion. The issues I initially had with
fossil were due to a misunderstanding about how fossil works. An
issue is that clicking the help button in the fossil UI gives a
wall of commands. That is fine if you already understand the
concept of the base operations and just need a quick syntax
reference. But when trying to learn fossil from scratch,
confusion sets in when looking at most of the commands without
an understanding of why/when/should it be used. As it turns out,
most of the commands are not used on a normal basis which just
confuses a newbie without knowing what is/not important.

I think the documentation should group the most commonly used
commands from the master list. Maybe make several groups
presented in most-used to rarely-used groupings. A primer should
avoid permuting the possible operations until later (it just
adds to the confusion) and focus on a complete real example with
the concepts explained as though the reader is seeing it for the
very first time.

Regarding my command line comment. Originally I misinterpreted
how fossil works. Here is how I thought it worked based on the
explanations how to use it. (Note this was my original
interpretation and have since figured out how it really works).

It seemed as though fossil was basically a ticket/wiki database
that had a fancy way of zipping groups of files together.
Without understanding the concept how it works, I derived that
clone basically sent a zipped package of files, you work on the
files, then zip them back up and then someone manually has to
conditionally decide what to merge back into the main
repository. That is what I derived from the documentation. As
such I initially saw fossil as a burden to use that did not
really add any value to my workflow.

I was not aware that doing a commit or sync automatically
updated the main repository. That should be the very first topic
of discussion in the documentation (with a better explanation
and example). The documentation seems to imply that only the
local copy is modified, which is why I was confused about the
server command line issue. I was trying to figure out how
changes to my local copy made it back into the main copy on the
server. The command line I was referring to was the command line
on the server not the local workstation. The documentation seems
to read as though to get the local copy back into the main
repository requires a bunch of commands need to be executed on
the server command line.

The documentation needs a newbie primer that better explains how
commits and syncing works. I now mostly figured it out, but was
initially discouraged because of the seemingly (incorrect)
concept of operation for syncing with the main repository.

A problem with most manuals for many software products is that
an assumption is made that the reader already understands the
concept of operation. If the reader is confuzzled at the start,
then explanations of the commands do not absorb without an
understanding why it is being done.


-------------------------
Scott Doctor
***@scottdoctor.com
-------------------------

Post by Warren Young

How do they do such over the internet without having command line access?

Are you actually saying that your fellow researchers don’t have access to the command line on their own workstations?
I do understand that some managed PC installations do try to turn off the local OS command terminal. An IT industry columnist I follow calls such people the Value Prevention Society, because they frequently take actions to remove the value we should expect to get from user-owned PCs over mainframes and such.
If you actually do find yourself operating in such a benighted environment, you could build a GUI wrapper program around the fossil.exe binary. I’m not talking about anything grandiose; maybe half a day of time in your favorite GUI builder. You could do this in anything from VB to Tcl/Tk to HTML Applications. You could probably even do it in FileMaker. :)
(Yes, I’m making a leap here that you’re using Windows. Organizations that allow use of other OSes generally don’t even *try* to lock their users out of the local command line.)

Seems adding files, doing check-ins, merges, should all be part of the UI.

Someone has to do it. Patches will be thoughtfully reviewed. :)
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Andy Bradford]

Regarding my command line comment. Originally I misinterpreted how
fossil works.

Thank you for being candid about what made your misunderstand how Fossil

The documentation needs a newbie primer that better explains how
commits and syncing works. I now mostly figured it out, but was
initially discouraged because of the seemingly (incorrect) concept of
operation for syncing with the main repository.

Probably a review of the Fossil documentation is in order, with
particular attention being made on how things work from a high-level
view.

Thanks,

Andy

[Adam Jensen]

On 10/24/2016 01:33 PM, Scott Doctor wrote:
[snip]

I think the documentation should group the most commonly used commands
from the master list. Maybe make several groups presented in most-used
to rarely-used groupings. A primer should avoid permuting the possible
operations until later (it just adds to the confusion) and focus on a
complete real example with the concepts explained as though the reader
is seeing it for the very first time.

[snip]

The documentation needs a newbie primer that better explains how commits
and syncing works. I now mostly figured it out, but was initially
discouraged because of the seemingly (incorrect) concept of operation
for syncing with the main repository.
A problem with most manuals for many software products is that an
assumption is made that the reader already understands the concept of
operation. If the reader is confuzzled at the start, then explanations
of the commands do not absorb without an understanding why it is being
done.

Déjà vu

http://www.mail-archive.com/search?l=fossil-users%40lists.fossil-scm.org&q=subject:%22\[fossil\-users\]+Pedagogy+Think+Tank+or+Documentation+Framework+RFC%22&o=newest

But there isn't much of a feedback mechanism in the software engineering
process to harness and utilize this information - it's still all done in
a willy-nilly, back-channel, human-toil fashion.

C'est la vie

[Warren Young]

The issues I initially had with fossil were due to a misunderstanding about how fossil works. An issue is that clicking the help button in the fossil UI gives a wall of commands.

If the repository’s /help URL is where you started to learn about how Fossil works, no wonder you’re confused. :)

Have you read the Schimpf book, at least through chapter 3?

https://www.fossil-scm.org/schimpf-book/doc/2ndEdition/fossilbook.pdf

Your issue comes up on page 31, which might seem late in the discussion for something so fundamental, but if you look at the table of contents, you can see that it’s just because the author wanted to cover other more fundamental things first.

The equivalent to the repo’s /help URL doesn’t appear until two chapters later in the Schimpf book, because /help is a command reference, not a tutorial.

I think the documentation should group the most commonly used commands from the master list.

I don’t think trying to contort the command reference into a tutorial will solve the base problem. Prose works better than command lists for bringing new users on board. Thus the Schimpf book.

And if you say, “Why didn’t I see this before?” then I’ll point out that it’s the fifth link on the Docs page at fossil-scm.org. :)

The first link on that page takes you to a Quick Start guide, and in the Making Changes section, it *does* talk about autosync, which is how local changes update the remote repository that you cloned from.

It seemed as though fossil was basically a ticket/wiki database that had a fancy way of zipping groups of files together.

You’re going to get into a lot of trouble trying to think of Fossil as a fancy sort of zip file. That’s a wholly unhelpful abstraction.

What is Fossil like? Hmmmm. I feel like a zen master being asked about the nature of butterflies. Every analogy I can think of either breaks down too quickly to be useful or it gets into details too quickly to be helpful.

I mean, I can’t exactly just point you at this:

https://www.fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki

and expect you to go, “Oh, of course that’s how it works!” :)

I don’t know that Fossil is all that close to any other software system you’ve likely used before. It isn’t even all that much like its close competitors, Git, Mercurial and such.

You sound like you might be a research scientist, or IT support for research scientists, so how about this for an analogy: Fossil vs Git is like Mathematica vs Maple, or Origin vs. Gnuplot. And Fossil vs Zip is like Mathematica vs. Python, or Origin vs. Excel. You can draw parallels between each of these pairs, but to call them interchangeable is to misunderstand at least one of the alternatives.

It’s best to just take Fossil on its own terms, and not to try to think of it as like anything else you’ve ever used. Fossil is Fossil.

I derived that clone basically sent a zipped package of files

Better to say that clone retrieves the complete history of the project, not just files, but also wiki pages, checkin comments, branch and tagging info, tickets, etc.

The only overlap between the way Fossil artifact data are stored and how zip files work is that the zlib compression library used by Fossil to do lossless compression of data at rest and on the wire is more or less the same thing as the compression algorithms used in Zip files.

But unlike zip files, Fossil doesn’t model a hierarchical filesystem at its core, and zlib vs zip totally ignores delta compression, which has far more practical effect on the final size of a typical Fossil repository.

And even that aside, that view of Fossil ignores many other things like tags, branches, tickets, artifact IDs, etc.

then someone manually has to conditionally decide what to merge back into the main repository.

In a normal software development project, manual merges are rare.

However, your earlier description makes me believe you might be storing binary data, and on top of that, the data itself might be totally different each time. That is, unlike with software source code, your use doesn’t amount to evolving text files by relatively small amounts on each checkin. That will prevent Fossil’s automatic conflict resolution from working, which means you’ll have to resort to social means to work out such conflicts.

The documentation seems to imply that only the local copy is modified

Which documentation, specifically? There’s a lot of it.

I’m still not sure if you just started in the wrong place or if one of the sane newbie entry points really does need to be improved.

The documentation seems to read as though to get the local copy back into the main repository requires a bunch of commands need to be executed on the server command line.

This is an example where I need a specific URL to understand your problem.

A problem with most manuals for many software products is that an assumption is made that the reader already understands the concept of operation.

Yes. Because Fossil is such a late arrival to the world of DVCSes and DVCSes are such a recent contribution to the wider world of VCSes that there is going to be an assumption that you’ve used one of Fossil’s competitors or predecessors. That’s just statistics; relatively few people will come to Fossil completely clueless.

It’s kind of like how Google Docs’ Help doesn’t explain how word processors work. They expect that Docs is not your first word processor.

(Which makes me wonder how all these kids coming up on Chromebooks are figuring this stuff out?)

[Adam Jensen]

Post by Warren Young
I don’t know that Fossil is all that close to any other software
system you’ve likely used before.

Isn't it a file (version) management system based on an embedded database?

Post by Warren Young
My current workflow uses a database (was filemaker but switched to
sqlite a while ago) like a library card catalog with notes and status
fields.

It sounds like you rolled your own file management system; the
difference being that, with Fossil, the managed files are stored *in*
the database.

For a while I imagined it would be useful if the Fossil file management
system were also capable of tracking and referencing files that are not
stored in the database. But after thinking more about the requirements
and use-cases, Fossil is probably in a funky territory of being too
light-weight in its capabilities to be the solution, and too monolithic
to be incorporated into a solution.

It has however attracted/inspired several people from the
research/experimentation arena (to the mailing list) who need a
tool-suite that supports modern [science][1] with software engineering
and data analysis methods. Again, I don't think Fossil is the solution
to this open problem.

[1]: By "science" I mean knowledge engineering informed by
epistemological sophistication and a high traction with reality.

[Warren Young]

Post by Adam Jensen

Post by Warren Young
I don’t know that Fossil is all that close to any other software
system you’ve likely used before.

Isn't it a file (version) management system based on an embedded database?

Under casual inspection, Fossil presents itself to the user that way, but if you dig into the way it actually works, you quickly find many places where Fossil doesn’t behave like a POSIX filesystem. (Or an NTFS one, for that matter.)

1. Fossil’s file storage mechanism isn’t fundamentally hierarchical. If you have a file called foo/bar/qux.c checked into the repo, its stored name is “foo/bar/qux.c” not “qux.c” which happens to live in a directory called “bar”.

2. Fossil’s low-level storage mechanism doesn’t have any concept of directories except as parents of a file, which is all Fossil really cares about. Largely this follows from point 1, but there are other knock-on effects, such as that you can’t store an empty directory in Fossil.

3. Symlinks continue to have impedance mismatch problems w.r.t. POSIX semantics. For example, there was the fix merged into trunk just 20 days ago allowing a symlink stored in Fossil to point to a directory. Unix solved this in 1983 with the release of 4.2BSD, but Fossil didn’t implement this use case until 2016, which is the sort of thing that happens when you’re not setting out to build a POSIX filesystem from the start. (I’m not laying blame, I’m just pointing out that different goals get different results.)

4. fossil mv and rm don’t behave like POSIX requires unless you give --hard or build Fossil in a nonstandard way and set an option that’s cleared by default.

5. Fossil’s understanding of file permissions is pretty much just a least-common-denominator subset of the logical intersection of Windows and POSIX permissions.

There is an experimental (?) feature of Fossil allowing it to operate as a FUSE filesystem. (fossil help fusefs) I suspect if you tried to use it that way for any complex software build system — say, that of Firefox — that you’d run into one or more of the above problems, or perhaps others I haven’t cataloged, as the build system makes assumptions about POSIX semantics that Fossil simply doesn’t provide.

[Warren Young]

Post by Warren Young
There is an experimental (?) feature of Fossil allowing it to operate as a FUSE filesystem.

I’ve just peeked into the code for that, and it appears the Fossil fusefs feature is read-only.

If someone were to make this FuseFS feature understand filesystem modification operations, such that each modification caused a Fossil checkin, then my hypothesis that it would break many real-world software build systems would be testable.

[Adam Jensen]

Post by Warren Young

Post by Adam Jensen
Isn't it a file (version) management system based on an embedded database?

Under casual inspection, Fossil presents itself to the user that way, but if you dig into the way it actually works, you quickly find many places where Fossil doesn’t behave like a POSIX filesystem. (Or an NTFS one, for that matter.)

[snip]

By file management system (as opposed to a filesystem) I mean something
more along the lines of managing the logistics, accounting, and
presentation of files (rather than simply the storage of files).

Post by Warren Young
There is an experimental (?) feature of Fossil allowing it to operate as a FUSE filesystem. (fossil help fusefs) I suspect if you tried to use it that way for any complex software build system — say, that of Firefox — that you’d run into one or more of the above problems, or perhaps others I haven’t cataloged, as the build system makes assumptions about POSIX semantics that Fossil simply doesn’t provide.

If a class of files were managed by Fossil that were not stored in the
database but, rather, in the filesystem, it seems like FUSE might be a
way to present various views (or checkouts) to a user.

The current implementation seems to be a bit primitive and probably
isn't usable for large binary files.

http://www.mail-archive.com/fossil-***@lists.fossil-scm.org/msg23865.html