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