Discussion:
Why no EXE+DLL like SQLite?
(too old to reply)
Gilles
2018-08-05 18:56:09 UTC
Permalink
Hello,

Out of curiosity, why isn't Fossil split into the engine in a DLL and a
CLI in an EXE, like SQLite?

I'm only a casual programmer, but I assume it would have made it easier
to build a GUI by calling functions within the DLL.

At this point, it seems like all of the Windows GUI (Fuel,
vcs-ramdebugger, Jurassic-Fossil) are abandonware.

Thank you.
Stephan Beal
2018-08-05 19:28:33 UTC
Permalink
Post by Gilles
Hello,
Out of curiosity, why isn't Fossil split into the engine in a DLL and a
CLI in an EXE, like SQLite?
I'm only a casual programmer, but I assume it would have made it easier
to build a GUI by calling functions within the DLL.
At this point, it seems like all of the Windows GUI (Fuel,
vcs-ramdebugger, Jurassic-Fossil) are abandonware.
Very, very long story very, very short: reimplementing fossil as a library
requires a massive effort. i started to do so back in 2013 or 14, but
chronic RSI effectively removed me from the programming world in late 2014,
allowing me only tiny scraps of programming now and then. (As of 3 days
ago, i'm officially an early retiree because of that.) Unfortunately,
fossil's addition, in the mean time, of SHA-256 means that libfossil is no
longer core-compatible with fossil and would require an unknown amount of
effort to make it so.

Search the mail archives for libfossil for the full story.

https://fossil.wanderinghorse.net/r/libfossil
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Gilles
2018-08-05 20:02:14 UTC
Permalink
Post by Stephan Beal
Very, very long story very, very short: reimplementing fossil as a
library requires a massive effort.
Too bad. Thanks for the info.
Richard Hipp
2018-08-05 20:02:27 UTC
Permalink
Post by Gilles
I'm only a casual programmer, but I assume it would have made it easier
to build a GUI by calling functions within the DLL.
How does adding an extra component and a bunch of new interfaces make
a program easier to build? I think that the key to building complex
systems is to keep them as simple as possible. If you can omit a
DLL/shared library and all the maintenance and interface design
associated with it, then why wouldn't you?
--
D. Richard Hipp
***@sqlite.org
Gilles
2018-08-05 20:14:16 UTC
Permalink
Post by Richard Hipp
How does adding an extra component and a bunch of new interfaces make
a program easier to build? I think that the key to building complex
systems is to keep them as simple as possible. If you can omit a
DLL/shared library and all the maintenance and interface design
associated with it, then why wouldn't you?
I was asking this naïve question because
1. SQLite is a DLL + EXE package
2. There's no maintained GUI for Fossil.
John Pateman
2018-08-05 20:46:23 UTC
Permalink
Re Your point (2)

There may not be a GUI for Windows (I don’t use Windows) but there is is a nice ‘Tortoise-like’ GUI for Fossil on macOS - Snail Fossil.
Post by Richard Hipp
How does adding an extra component and a bunch of new interfaces make
a program easier to build? I think that the key to building complex
systems is to keep them as simple as possible. If you can omit a
DLL/shared library and all the maintenance and interface design
associated with it, then why wouldn't you?
I was asking this naïve question because
1. SQLite is a DLL + EXE package
2. There's no maintained GUI for Fossil.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Gilles
2018-08-05 20:55:59 UTC
Permalink
Thanks for the info, but like 90% of deskop users, I run Windows. I gave
up on deskop Linux, even though I give it a try every year or so just to
check it out.

I'm not arguing. It's just that Fossil is such a great SCM application
that I guess it would benefit even more users if it were available as a
GUI application instead of a CLI — which, I would venture, very few
non-developers, in this day and age, even know there is such as thing.)
Post by John Pateman
Re Your point (2)
There may not be a GUI for Windows (I don’t use Windows) but there is is a nice ‘Tortoise-like’ GUI for Fossil on macOS - Snail Fossil.
Post by Richard Hipp
How does adding an extra component and a bunch of new interfaces make
a program easier to build? I think that the key to building complex
systems is to keep them as simple as possible. If you can omit a
DLL/shared library and all the maintenance and interface design
associated with it, then why wouldn't you?
I was asking this naïve question because
1. SQLite is a DLL + EXE package
2. There's no maintained GUI for Fossil.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Artur Shepilko
2018-08-06 16:18:09 UTC
Permalink
How would you want to use such a GUI?
I mean practically what is a non-programmer user workflow that
involves a VCS interaction via GUI?

The reason I ask, is that on several occasions I tried to convince
"ordinary" users to incorporate a VCS into their daily tasks. Not just
Fossil VCS, but Git and back in time SVN with GUI too. All of these
attempts were unsuccessful, mainly due to lack of perceived utility.

This gave me understanding that ordinary users deal with a different
"revision" workflow than programmers. As the notion of a "project"
often not clearly defined. Such users are often concerned with just a
single Word document which then balloons to tie in a whole bunch of
other resources. In such a setup a "change" representation is not what
VCS's diff could produce.

Also, there was not much of a need to retrieve previous states of such
a document while the work is still in progress. Only after reaching a
"final" version, such users would try to preserve the state before
making "tweaks". This would be often done by creating a named copy
(either of folder or just of TheFile).

Collaborative use is slightly more convincing, yet even then the
individual user workflow is still the same. The company backup policy
takes over the VCS functions.

Only one use-case, a "document tracking", was the most receptive.
Mostly for the management and compliance convenience, not for the
workflow. In such a case, tagging, searching and referencing were
requested.

So my feeling is that no amount of explanation or "instructions" would
convert such users to make use of a VCS in any form, GUI or not. VCS
would be perceived as an additional and annoying hoop to jump through.

So I wonder, how do you see your use-cases and GUI VCS workflow?
Thanks for the info, but like 90% of deskop users, I run Windows. I gave up
on deskop Linux, even though I give it a try every year or so just to check
it out.
I'm not arguing. It's just that Fossil is such a great SCM application that
I guess it would benefit even more users if it were available as a GUI
application instead of a CLI — which, I would venture, very few
non-developers, in this day and age, even know there is such as thing.)
Re Your point (2)
There may not be a GUI for Windows (I don’t use Windows) but there is is a
nice ‘Tortoise-like’ GUI for Fossil on macOS - Snail Fossil.
How does adding an extra component and a bunch of new interfaces make
a program easier to build? I think that the key to building complex
systems is to keep them as simple as possible. If you can omit a
DLL/shared library and all the maintenance and interface design
associated with it, then why wouldn't you?
I was asking this naïve question because
1. SQLite is a DLL + EXE package
2. There's no maintained GUI for Fossil.
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Richard Hipp
2018-08-06 01:16:57 UTC
Permalink
Post by Gilles
2. There's no maintained GUI for Fossil.
I would argue that running "fossil ui" is your GUI.
--
D. Richard Hipp
***@sqlite.org
Steve Landers
2018-08-06 01:18:56 UTC
Permalink
Put differently, what can’t you do with “fossil ui” that you can do with a native client?

Drag and drop is the only one I can think of and I suspect that’s a good thing.


-- Steve
Post by Richard Hipp
Post by Gilles
2. There's no maintained GUI for Fossil.
I would argue that running "fossil ui" is your GUI.
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Gilles
2018-08-06 07:14:47 UTC
Permalink
I guess that's another reason why there's no desktop UI for fossil.

It's just that I prefer desktop apps to web apps generally, but I can
live with CLI + UI if there's nothing else.

This thread was not meant as criticism; It was just a question.
Post by Steve Landers
Put differently, what can’t you do with “fossil ui” that you can do
with a native client?
Drag and drop is the only one I can think of and I suspect that’s a good thing.
-- Steve
Post by Richard Hipp
Post by Gilles
2. There's no maintained GUI for Fossil.
I would argue that running "fossil ui" is your GUI.
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Steve Landers
2018-08-06 07:16:28 UTC
Permalink
Post by Steve Landers
Put differently, what can’t you do with “fossil ui” that you can do with a native client?
Drag and drop is the only one I can think of and I suspect that’s a good thing.
And also push notifications. While it can be done with web tech I don’t advocate it for fossil.

Steve
Post by Steve Landers
Post by Richard Hipp
Post by Gilles
2. There's no maintained GUI for Fossil.
I would argue that running "fossil ui" is your GUI.
--
D. Richard Hipp
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Warren Young
2018-08-06 21:57:35 UTC
Permalink
Post by Gilles
1. SQLite is a DLL + EXE package
A great many programs have need for an embedded DBMS. Very few programs have need for an embedded DVCS.

Note also that these are empirical observations, rather than opinions.
Post by Gilles
2. There's no maintained GUI for Fossil.
Looking for a project? :)
Ron W
2018-08-07 00:10:08 UTC
Permalink
Date: Mon, 6 Aug 2018 09:18:56 +0800
Subject: Re: [fossil-users] Why no EXE+DLL like SQLite?
Put differently, what can’t you do with “fossil ui” that you can do with a
native client?
You can't do:

fossil add
fossil ci
fossil changes
fossil extras

and a few others.

With some IDEs, you can define an interface to the above commands, which
will run the command in a terminal (or command) window using command
templates you define.

For example:
fossil add ${selected_resource_path}
will tell Eclipse to run the "fossil add" command with the workspace
relative path of the currently selected file.
Ron W
2018-08-07 01:21:12 UTC
Permalink
Date: Mon, 6 Aug 2018 11:18:09 -0500
Subject: Re: [fossil-users] Why no EXE+DLL like SQLite?
How would you want to use such a GUI?
I mean practically what is a non-programmer user workflow that
involves a VCS interaction via GUI?
...
So my feeling is that no amount of explanation or "instructions" would
convert such users to make use of a VCS in any form, GUI or not. VCS
would be perceived as an additional and annoying hoop to jump through.
So I wonder, how do you see your use-cases and GUI VCS workflow?
In the case of my employer, transitioning away from a hugely expensive (as
in a large annual license fee) to SVN. Most of the non-programmers like it
much more than the old system. Partly because because a set of documents
could be identified by project code and SVN revision number, instead of a
list of document numbers and revision numbers. with the help of a Power
Shell script from IT, each user has, on their PC, a workspace for each
project they are working on. Then they use TortoiseSVN to (mostly) commit
changes to their documents, sometimes to fetch older versions. Many of the
users are now making almost daily commits, not just just when making
official releases of their documents.

Unfortunately, fossil - and other DVCSs - use less friendly version IDs
than the revision numbers SVN uses. But, I suspect that, after using the
old system, the non-programmers would have welcomed Fossil, even with its
unfriendly version IDs - except for the lack of a GUI front end to add,
commit and update the user's workspace.

I never tried Sharp Fossil, but Fuel was a very clunky GUI. I think
non-programmers would be unwilling to put up with it. And I seriously doubt
it's a project corporate IT departments would be willing to take on. (The
Power Shell script I mentioned is very simple. It presents the user with a
folder-and-file style interface to select a project, then creates a folder
in the user's projects folder and does a SVN checkout into that folder.

I suspect most corporate IT directors would choose SVN+TortoiseSVN for a
document management system for non-programmers, as an alternative to the
kind document management system my employer used to use. If they did choose
a DVCS, then I think it would be Mercurial+TortoiseHg or git+Tortoisegit,
before they'd consider Fossil.

(As I've mentioned before, my fellow programmers and I, use Fossil for our
day-to-day VCS needs and only use SVN for official releases. We used to use
SVN for day-to-day use, but then the "process gurus" decided to link SVN to
an issue tracking system that makes every commit a 2 hour (or more) task.
We use Fossil "under the radar" and the process gurus seem to think that
our reduced use of SVN is a good thing, so haven't asked why we are using
it less.)
Gilles
2018-08-07 01:42:54 UTC
Permalink
Post by Ron W
I never tried Sharp Fossil, but Fuel was a very clunky GUI. I think
non-programmers would be unwilling to put up with it.
As a simpler alternative, the "GUI" could just be implemented as an
extension to Windows Explorer, where users would just right-click a
folder to perform the main tasks provided by Fossil (commit, gdiff, etc.)
s***@gmail.com
2018-08-07 13:54:56 UTC
Permalink
Hmmm, that sounds like TortoiseFossil?
I would deploy that if available. :)
Post by Ron W
I never tried Sharp Fossil, but Fuel was a very clunky GUI. I think
non-programmers would be unwilling to put up with it.
As a simpler alternative, the "GUI" could just be implemented as an
extension to Windows Explorer, where users would just right-click a folder
to perform the main tasks provided by Fossil (commit, gdiff, etc.)
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Gilles
2018-08-07 14:03:11 UTC
Permalink
Does it work?

"What you'll find here is a work in progress to have a Tortoise-style
tool for Fossil repositories. Currently there is no release just yet,
there are no commands implemented as of right now, but file overlays are
working great."
http://www.tortoisefossil.org/index.cgi/index
Post by s***@gmail.com
Hmmm, that sounds like TortoiseFossil?
I would deploy that if available. :)
Post by Ron W
I never tried Sharp Fossil, but Fuel was a very clunky GUI. I
think non-programmers would be unwilling to put up with it.
As a simpler alternative, the "GUI" could just be implemented as
an extension to Windows Explorer, where users would just
right-click a folder to perform the main tasks provided by Fossil
(commit, gdiff, etc.)
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
<http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users>
_______________________________________________
fossil-users mailing list
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Donald Griggs
2018-08-07 14:14:47 UTC
Permalink
Re: http://www.tortoisefossil.org/index.cgi/index "What you'll find
here is a work in progress "

Unfortunately, it appears the project is at least on hiatus, if not
abandoned. The last code commit in the timeline was in late 2014.
Gilles
2018-08-07 14:24:33 UTC
Permalink
Re: http://www.tortoisefossil.org/index.cgi/index     "What you'll
find here is a work in progress  "
Unfortunately, it appears the project is at least on hiatus, if not
abandoned.  The last code commit in the timeline was in late 2014.
It's a known pattern.

https://fuel-scm.org/fossil/index
2015/08/23 Fuel version 1.0.1 has been released

http://code.google.com/p/jurassic-fossil/
Latest commit 5b8862e  on Jul 21, 2011

http://repository.mobile-developers.de/cgi-bin/ikoch/sharpfossil
"The requested URL /cgi-bin/ikoch/sharpfossil was not found on this server."
Stephan Beal
2018-08-07 18:12:55 UTC
Permalink
Post by Donald Griggs
Re: http://www.tortoisefossil.org/index.cgi/index "What you'll find
here is a work in progress "
Unfortunately, it appears the project is at least on hiatus, if not
abandoned. The last code commit in the timeline was in late 2014.
That time frame is familiar to me, so i had to check... a couple timeline
entries mention his use of libfossil, and late 2014 was when chronic RSI
knocked me out of my hobby projects (which included libfossil).
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Gilles
2018-08-07 18:23:19 UTC
Permalink
Post by Stephan Beal
That time frame is familiar to me, so i had to check... a couple
timeline entries mention his use of libfossil, and late 2014 was when
chronic RSI knocked me out of my hobby projects (which included
libfossil).
Too bad no one read, willing and able took over its development.

http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/wiki/home
Artur Shepilko
2018-08-07 18:26:04 UTC
Permalink
Post by Ron W
project they are working on. Then they use TortoiseSVN to (mostly) commit
changes to their documents, sometimes to fetch older versions. Many of the
users are now making almost daily commits, not just just when making
official releases of their documents.
Thank you for sharing this.
So the add/diff/branch/merge/pull SCM functionality is mostly
under-utilized or even remains unused.

Basically, the commit is used as an alternative Save. This is somewhat
similar to how updates are handled in wiki/wordpress etc., where one
just tracks the saves, without even comment attribution, just a
timestamp.

For such a use-case it'd be more user-friendly if there would be some
kind of hook into the Save/Save As action (and perhaps Open) to allow
more transparent VCS interactions. Not sure what's the best way to
implement this, as it would be tied to the application which handles
the edits. A plugin?? Or may be some watch service that polls for
changes and picks up a new version and does the commit... Just
thinking about finding a way to organically integrate VCS into
ordinary user's workflow.

BTW, back in the days of OpenVMS, file versioning was supported by OS
itself, not sure if it has seen a huge demand, other than a need to do
'purge' to clean up the directories. But in my experience it was
mostly an "Undo" feature, still the versioning was fairly transparent
to the ordinary user. VCS should be able to handle this much better if
it could be as much transparent to the user.
Ron W
2018-08-10 22:05:49 UTC
Permalink
Date: Tue, 7 Aug 2018 13:26:04 -0500
Subject: Re: [fossil-users] Why no EXE+DLL like SQLite?
Post by Ron W
project they are working on. Then they use TortoiseSVN to (mostly) commit
changes to their documents, sometimes to fetch older versions. Many of
the
Post by Ron W
users are now making almost daily commits, not just just when making
official releases of their documents.
Thank you for sharing this.
So the add/diff/branch/merge/pull SCM functionality is mostly
under-utilized or even remains unused.
The users do use add when they create a new document. But don't use
branch/merge or diff features (SVN doesn't have pull).
Basically, the commit is used as an alternative Save.
Something like that. The pay-were DMS that was previously used had a GUI
similar to TortoiseSVN, so the usage is very similar.
For such a use-case it'd be more user-friendly if there would be some
kind of hook into the Save/Save As action (and perhaps Open) to allow
more transparent VCS interactions.
TortoiseSVN, as a Windows Explorer extension, goes halfway in that
Open/Save dialogs summoned by applications are able to access SVN
functions. Since the DMS worked this way as well, the users only had to
adapt to slightly different details.

Taking the further step would be nice. I don't know if/how this could be
done.
BTW, back in the days of OpenVMS, file versioning was supported by OS
itself, not sure if it has seen a huge demand, other than a need to do
'purge' to clean up the directories. But in my experience it was
mostly an "Undo" feature, still the versioning was fairly transparent
to the ordinary user. VCS should be able to handle this much better if
it could be as much transparent to the user.
I recall some discussion about adding fsuser support to Fossil so this
could be done. I don't remember if anyone actually implemented it. For MS
Windows, it might be possible to borrow code from Samba to do this.
Warren Young
2018-08-11 17:24:12 UTC
Permalink
Post by Ron W
I recall some discussion about adding fsuser support to Fossil
Yes, it was checked in years ago. See src/fusefs.c.

Getting FUSE working on Windows is reportedly difficult, however:

https://superuser.com/q/179436/14927
Post by Ron W
so this could be done.
Fossil-via-FUSE sounds pretty risky to me. What happens if the host application says “File > Save” but there’s a merge conflict? Does the app give an error dialog like “File I/O error”? Will the user understand what that means and why it’s happening? Does the user then manually do a “fossil up” and then save their copy over the top, effectively reverting the other user’s work?

At some point, you can’t insulate the users from having to know what version control is all about.
Loading...