Perhaps another factor for minor popularity of Fossil SCM is a lack of plugins for major IDEs.
I don't believe this should be such an obstacle, as most plugins implement only a part of SCM client features, thus asking you to resort to command-line for certain functions. Still, for a lot of developers the expected interaction with "everything" is through IDE. There seems to be a Git or SVN plugin for every possible IDE, yet Fossil lags in that department.
JetBrains has a nice Fossil plugin (for IDEA); that's about it, nothing for VisualStudio, eclipse, Xcode etc. Catch 22 -- no demand, no plugin.
Not that availability of plugins has to be such a big deal for a SCM adoption, but sure this helps a lot to increase any SCM's visibility and accessibility. In case of Fossil this probably will have to be another community effort.
Seems like you were trying to create a centralized server, akin to GitHub or ChiselApp to serve as a main repo and registration site, allowing users to self-register.
Fossil as such does not need a central server; each user may just as well be self-sufficient, and if needed, to share his/her repo to other users (fossil server).
Still one easy way to accomplish the centralized setup is to designate one Fossil instance as the main/origin, create a repo, and launch 'fossil server', it will show the port on which it listens. Then make other users connect to the main by http://hostname:port.
To allow users to self-register, you need to log-in as admin-user and check an option in Admin::Access:Allow users to register themselves. Keep it checked at least until all of your users have registered. Make sure users have a Developer privilege, so that they can push the changes to the main repo.
This will add user names to the central repo, and will prompt for authorization at clone/commit/pull/push/update. In case the registered username is different from local login username, the users may need to make it as local fossil admin (`fossil clone <url> --admin-user <username>`). Then after `fossil open`, make this username as cloned repo default (`fossil user default <username> --user <username>`)
HTTP connect is fairly robust, with additional layer of security added on the Fossil's side to somewhat compensate for the clear-text login. Should suffice in trusted environment.
Your LAN should have no problems routing this as it's indeed a local traffic.
BTW, Fossil has a nice convenience feature called "autosync" which makes login/password use transparent, only enter it once and then all commits would automatically attempt to sync to origin repo. It can be turned-off in settings if not needed, on per-clone basis (fossil set autosync off)
IMHO, no need to actually mirror. You may simply keep the same project under both Git and Fossil, just add ".fslckout" and "_FOSSIL_" to your .gitignore.
1) Setup Git repo on GitHub.
2) Clone the Git repo.
3) Create local Fossil repo.
4) Add the cloned project to Fossil repo.
5) Work with Fossil.
6) Add/commit completed features to Git.
7) Push to GitHub.
8) Pull/Update respectively.
A bit of overhead, but for personal projects easy to get used to.
Indeed, a Fossil repo is actually a SQLite db, one you may as well open and tinker with (at your own risk :). By the same token, it's just as easy to back these repos up, as much as copying the db-file. Or automatically push to a remote. Cron job -- done!
Of course, mishaps happen, bugs too. Blaming SCM is easy, blaming no-backup habits, well, that's personal.
Fossil does get progressively more potent, I can attest to this on my user experience at least from v1.19 to v1.35. Many convenience features are added, yet core remains stable.
I think everyone agreed that having an SCM on a project is a must. Everyone most likely is using some SCM already, often-times the choice is made by someone else upstairs or in the history. Git, bzr, hg, svn, TFS (ahem) -- you've just got to use what you've got.
HOWEVER, you may just as well use an SCM that is more __optimal__ for your development style, say, frequent commits, branching, stashes, private branches and then just pump the completed stages into "official" SCM -- kind of layering the version control.
You can install Git or bzr etc. just for yourself? Good!, but not everyone may have such a policy. Fossil does not require installation, it's a self-contained executable, you may just as well build it from source and use it in your account.
Just as simply, the same project directory may be tracked by Fossil in addition to the whatever is the "official" SCM, the only file it places in working dir is ".fslckout".
I think, there's really no need to debate and pit SCMs against each other -- just use what works for you, your project, well, what fits in your own memory (it's true, Fossil command and options set is very compact, yet potent -- check it out!)
I don't believe this should be such an obstacle, as most plugins implement only a part of SCM client features, thus asking you to resort to command-line for certain functions. Still, for a lot of developers the expected interaction with "everything" is through IDE. There seems to be a Git or SVN plugin for every possible IDE, yet Fossil lags in that department.
JetBrains has a nice Fossil plugin (for IDEA); that's about it, nothing for VisualStudio, eclipse, Xcode etc. Catch 22 -- no demand, no plugin.
We faced this with our Qt projects, and went on to develop a Fossil SCM plugin for QtCreator: https://github.com/nomadbyte/qtcreator-plugin-fossil
Not that availability of plugins has to be such a big deal for a SCM adoption, but sure this helps a lot to increase any SCM's visibility and accessibility. In case of Fossil this probably will have to be another community effort.