
Fossil SCM - Tomte
https://www.fossil-scm.org/index.html/doc/trunk/www/index.wiki
======
bachmeier
Here's my story. I wanted to use version control on my research projects, but
asking my collaborators to use Git was too much. They were supposed to figure
out a staging area and pushing and pulling and then they'd get a bizarre error
about a merge conflict. They'd do a search and Stack Overflow told them to
type in an incantation. The repo is messed up, the collaborator goes back to
email, and I'm left sorting through the rubble formerly known as a repo.

I switched to Fossil a few months ago. Nice website that holds all the
information. fossil commit -m "Message" is all they need to know. If they
forgot to pull, it stops and tells them to do so. They type fossil update and
go on with their lives. Zero problems so far and a more productive workflow
overall.

~~~
bananaoomarang
This is a good point. I think once developers learn Git (or as much as they
need to use), then they forget how esoteric the the cli tool is.

I think a lot of devs have the attitude that a tool being more difficult to
use makes it a powerful one (cf. Vim/Emacs), whereas most people are happy
when tool does the three things they need to get from a=>b, b=>c, a=>c.

Maybe this is to do with our desire for everything to be as flexible as the
programming languages we write in. Most people don't view computers as blank
slates ready to do their bidding, but as systems where the behaviour of a few
facets is to be memorised without concerns for their mechanics or
abstractions. This is probably one of the reasons that mobile software is seen
as so easy to use, since it obscures/abstracts elements like the filesystem
from the user.

Glad to hear Fossil is friendlier.

EDIT: I should say that I am a heavy user of Vim, Emacs, Git and Arch Linux, I
am just saying that these tools often require a large up front investment, and
this can be detrimental as well as sensible.

~~~
gkya
> I think a lot of devs have the attitude that a tool being more difficult to
> use makes it a powerful one (cf. Vim/Emacs), whereas most people are happy
> when tool does the three things they need to get from a=>b, b=>c, a=>c.

While I agree that there are those who take pride in how spartan tools they
use, it's not correct to make blanket judgements about the whole suite of
_hackerware_. Emacs, for instance, is not difficult to use, it is a different
computing environment, which, when you get hold of it, can boost your
productivity. I've written many little programs in it that I use every day
which I'd never be able to write in other languages because a) I need to know
at least one GUI framework and many other libraries, b) no other environment
has the same use-hack-eval-use development experience, and c) the way you
create GUIs in Emacs is so effective (mixture of special-mode, plain text and
text with properties attached; all buffer-manipulation commands come in to
your _app_ out of nowhere, gratis) that one can set sth. working in their
first hacking session, and then on improve their tools while using it, all
interactive, whereas in all other GUI frameworks you're left alone with
widgets and a dev cycle that's nearly always approximately write-compile-
debug-compile.

Git, instead, is a plain tool for one purpose with an arcane user interface. I
believe the patch theory school of VCS tools (e.g. darcs) will overtake in
future when they'll smooth out their rough edges as they provide a very
intuitive way to work with code as a series of related changes.

~~~
oblio
Emacs is not difficult to use?

In order to get it to do half of what Notepad++ or Sublime or Kate do, you
have to spend hours and hours to learn it and configure it in the hope that
the investment will pay off and that the productivity gain will make up for
it. And despite what you might say there's no data you can point me to that
actually proves those increased productivity claims.

~~~
kaushalmodi
You are comparing Emacs with Notepad++. You are then not using Emacs as it's
supposed to be.

The actual power of Emacs is realized once you learn elisp. Coding,
documenting, commiting, blogging, browsing, file/dir manipulation, etc. all
can be done efficiently using the same familiar buffer editing philosophy
within Emacs.

------
cmrx64
Fossil is the SCM I always wish I were using, but for the benefit of external
collaborators, I stick with Git and GitLab (previously, GitHub). Fossil is a
lovely, small piece of software that does exactly what I want in a nice and
simple way. It's fast and uses SQLite for everything, making it easy to
programmatically extend it and munge its internal data.

~~~
maxpert
SQLite usage makes me wonder how will it behave over time with millions of
commits. Also makes me wonder how will it handle distribution.

~~~
BeetleB
To be honest, I'm very wary of using SQLite for storage for anything long
term. Over the years I've had a few SQLite databases become corrupt in various
software I use. Always a headache.

~~~
rogerbinns
SQLite has had corruption bugs but they have been exceeding rare. Far more
often it has been other factors that caused SQLite to become corrupt (ie it is
a victim not the cause).

[https://www.sqlite.org/howtocorrupt.html](https://www.sqlite.org/howtocorrupt.html)

[https://www.sqlite.org/testing.html](https://www.sqlite.org/testing.html)

------
krylon
I switched from Mercurial to Fossil for my personal projects about two years
ago and have been very happy with it so far. (Not that I think Mercurial is
bad, not at all).

The builtin Wiki was what really sold me on it, because it makes a great place
to gather notes and such.

This is one nice piece of software, at least for my needs.

------
rkeene2
I would also like to mention ChiselApp (
[http://ChiselApp.com/](http://ChiselApp.com/) ) offers free Fossil hosting. I
run this service, originally run and created by James Turner.

~~~
jccooper
Thank you super much!

------
cuspycode
For me, the ease of self-hosting my own source-code hub tipped the balance in
favor of Fossil SCM, after I abandoned Subversion. Ironically, the difficulty
of self-hosting Git was the raison d'être for why inherently centralized
services such as Github/Gitlab/etc were created in the first place, despite
all the nice talk about distributed systems. There is no a priori reason why
hosting a source code repo should be any different from hosting any random
blog page. And Fossil is the proof that it can work.

------
e12e
I tried using Fossil as a DVCS/Project management tool for a class I'm
currently teaching - but in the end I couldn't quite figure out self-
registration combined with allowing authenticated push in a way that worked
for ~25 students without needing much instruction/hand-holding.

If I'd had some form of user-database already, I could probably have gotten it
to work with a proxy in front - but for now I've ended up using gogs:
[https://gogs.io/](https://gogs.io/)

I'm not certain I actually prefer gogs to fossil, but apart for working as I
wanted/needed without much setup it had the dubious benefit of forcing me to
teach my students to use git, along with a rather cumbersome pull-request
system (gogs tend to hickup on commits that probably should've been possible
to fast-forward, possibly due to not forcing git to ignore white-space).

Dubious because as a bit of a mercurial fanboy, I think git has a frustrating
and opaque command line interface, not helped by the fact that a standard
workflow uses various "non standard" (as in: the most obvious) commands.
Benefit because learning git is unquestionably a valuable skill, due to the
popularity git enjoys, in no small part due to github's success.

I'd like to go back and revisit Fossil at a later time, but right now I'll
probably spend any time I can find on (investigating) migrating from gogs to
gitlab -- as it's turned out that the limits on pull-requests in gogs make it
complicated to use with large groups of people new to version control.

That said, I'm a strong believer in combining wiki, version control and issues
in a single repository supporting various DVCS workflows.

~~~
sytse
Glad to hear you're considering using GitLab. We have an importer for Gitea
but not for Gogs
[https://docs.gitlab.com/ee/workflow/importing/README.html](https://docs.gitlab.com/ee/workflow/importing/README.html)
so I think you might consider a batch import
[https://docs.gitlab.com/ce/raketasks/import.html](https://docs.gitlab.com/ce/raketasks/import.html)

~~~
pythonaut_16
I just started using this yesterday!

I setup a personal Gitea instance on Linode, but wanted to make sure I could
easily back up my repos in case I ever lose access or stop maintaining my
personal Linode server.

Gitlab made it easy to setup all of my repos to mirror and automatically
update from my Gitea daily.

(One slight bug, Gitlab does seem to always say the repos failed to import,
even when they're successful)

Thanks for the helpful feature!

~~~
sytse
Great to hear you're using GitLab already. Please consider creating an issue
for the 'repos failed to import, even when they're successful' that allows us
to reproduce it.

------
ftwynn
If anyone is interested in some of the deeper rationale behind SQLite and
such, the FLOSS Weekly episode on this was pretty good.

[https://twit.tv/shows/floss-weekly/episodes/320](https://twit.tv/shows/floss-
weekly/episodes/320)

------
Rexxar
The previous submission of the link to fossil-scm.org (
[https://news.ycombinator.com/item?id=12673229](https://news.ycombinator.com/item?id=12673229))
has some interesting comments from the creator.

------
oblio
My god, they've updated the CSS. It used to be quite a bit uglier. Now it's
not GitHub, but it's definitely lighter on the eyes.

Nice to see - I think that good tools should have UIs that at least come close
to the quality of their engineering.

~~~
bachmeier
While it's good to have a pleasant default, it's very easy to modify
everything about the website, including the CSS, the menu, the homepage...

But to me, the most beautiful UI is one that offers the functionality I need
while remaining lightweight.

------
cygned
Podcast with the creator of SQLite who also created Fossil, they also talk
about the latter. Definitely recommended.

[https://changelog.com/podcast/201](https://changelog.com/podcast/201)

------
pestaa
GitLab contributors, please take note.

Fossil's UI is very fast and the navigation is intuitive and discoverable.

I know it's on the roadmap, but it is so often an afterthought.

~~~
sytse
Thanks, we're indeed working on making the UI faster in
[https://about.gitlab.com/2017/02/06/vue-big-
plan/](https://about.gitlab.com/2017/02/06/vue-big-plan/)

I've clicked around in the UI of Fossil. It indeed is very fast. About the
navigation:

1\. Fossil has home, GitLab has a hamburger menu with different top level
view, Fossil doesn't seem to account for multiple project but I'm probably
overlooking something.

2\. Fossil timeline seems similar to GitLab Activity
[https://gitlab.com/gitlab-org/gitaly/activity](https://gitlab.com/gitlab-
org/gitaly/activity)

3\. Fossil code seems similar to GitLab Repository [https://gitlab.com/gitlab-
org/gitaly/tree/master](https://gitlab.com/gitlab-org/gitaly/tree/master)

4\. Fossil docs seems similar to GitLab help
[https://gitlab.com/help](https://gitlab.com/help) (in this case, for other
projects I think it has the documentation of the project, not sure what
standard they use)

5\. Fossil branches are in the GitLab repo view

6\. Fossil tickets are similar to the GitLab issues view

7\. Fossil wiki is similar to GitLab wiki

8\. Fossil includes a download tab, in GitLab that would be the tags view
[https://gitlab.com/gitlab-org/gitaly/tags](https://gitlab.com/gitlab-
org/gitaly/tags) to download the repo (not sure if this is always to download
Fossil or the specific project)

9\. The Fossil "More..." link looks like a sitemap.

What would you change in GitLab to make it more discoverable?

~~~
eslaught
The issue is not that Gitlab is missing any of the pieces. The issue, I
believe, is the organization of such pieces so that you can find them
intuitively.

This is admittedly a lot better in Gitlab today that it used to be. When I
started, I literally could not figure out basic things like how to get to a
specific repository inside of an organization. It also doesn't help that
Gitlab has chosen to use its own jargon for each of the basic concepts. A
"project" is a "repository" and a "group" is an "organization", etc. I can
kind of grok it, but I sometimes do a double take when something isn't where I
expect.

For example: In my mental model, "project" == "repository". But when I go to a
project home page like say [1], I don't see a code browser or commit list, or
options that obviously take me to either of those. Instead, I have to click
the "Repository" tab first. (It turns out that tabs can have second-level
tabs, which means those options are hidden initially and thus not
discoverable.) But I thought a "project" was a "repository"?

I fully realize the Gitlab notion of "project" may be more general than just a
"repository", but this is an example of the sort of cognitive dissonance that
I get navigating around the site.

At this point I've mostly made peace with the Gitlab interface, so it's a bit
hard for me to pull up examples like this now. And as I said above, the
interface has improved. But when I first started using Gitlab, there were a
_lot_ of things like this (little points of cognitive dissonance) which made
it seriously an uphill battle to even use the product.

[1]:
[https://gitlab.com/StanfordLegion/legion](https://gitlab.com/StanfordLegion/legion)

~~~
sytse
Thanks for the response, and I'm glad that it is better than it used to be.

In GitLab people can have a project without a repository, for example with
just a wiki or an issue tracker. For that reason we use different words for
it.

Single people also use GitLab as a single tenant we prefer to use the word
group over organization. That will also fit better when we introduce nested
groups in GitLab 9.0 [https://gitlab.com/gitlab-org/gitlab-
ce/issues/2772](https://gitlab.com/gitlab-org/gitlab-ce/issues/2772)

Good point about showing files by default, we're discussing that in
[https://gitlab.com/gitlab-org/gitlab-
ce/issues/26834](https://gitlab.com/gitlab-org/gitlab-ce/issues/26834)

Thanks for using GitLab!

~~~
pestaa
Thanks for the open discussion!

As eslaught pointed out, it's not about the obvious mistakes.

Unfortunately, the navigation is very fragmented. There's a left menu, which
should be the primary one, but it changes all the time depending on the
context.

The top menu is very inconsistent, presented in multiple layers, with
different styles for each level, using very low contrast text with no other
visual aid. There are no dropdowns or other ways to get to frequented pages
faster. Being aligned to center also prevents me from memorizing the UI
spatially (YMMV).

And there's also the issue with minimalistic buttons acting like links.

It is my humble opinion that rewriting the frontend in Vue will not, by
itself, alleviate the matter; however, fixing this part of the UX will make
GitHub and Atlassian _really_ run for their money.

~~~
dimitrie
Thanks for your feedback! This will an is becoming more and more a focus for
us!

To join the discussion see: [https://gitlab.com/gitlab-org/gitlab-
ce/issues/26348#note_23...](https://gitlab.com/gitlab-org/gitlab-
ce/issues/26348#note_23730202) or [https://gitlab.com/gitlab-org/gitlab-
ce/issues/18844#note_23...](https://gitlab.com/gitlab-org/gitlab-
ce/issues/18844#note_23731395)

------
simplehuman
Surprised to see no LDAP support.

[http://www.fossil-
scm.org/index.html/tktview?name=ec667f74f8](http://www.fossil-
scm.org/index.html/tktview?name=ec667f74f8)

~~~
djsumdog
From what I can tell from the issue, they're suggesting the load balancer or
server you put in front of Fossil to do the authentication (which can hit
LDAP/AD).

Sure you can't do fine grained control or permissions, but for small
shops/groups it seems like a good starting point.

~~~
lvh
You can sort-of hack it together offline, in that LDAP can be the source of
identity (via REMOTE_USER + frontend, as you mention), and that Fossil has a
reasonably fine-grained permissions model that you can (offline) sync from
LDAP.

------
sureshn
I am huge fan of fossil and using it for my side projects , I also wrote a
blog about it [https://fulstacker.wordpress.com/2016/04/11/all-you-need-
to-...](https://fulstacker.wordpress.com/2016/04/11/all-you-need-to-know-
about-fossil-scm/) . I am working on a React.JS Angular implementation of
Fossil which is still in its primitive stage. I plan to open source it some
day !

------
crux
I use Fossil whenever I can. Unfortunately, this means I have only ever used
it for projects where I'm the only contributor.

------
maxpert
It's good to see so many SCM systems showing up. But it makes me wonder how
many of them can actually work on GBs of codebase with over 1000 of
programmers checking in on daily basis. I my experience most of SCMs are fine
for small to medium projects, but they go down with crawling speeds and
sometimes even not working at all when it goes large scale.

~~~
tacostakohashi
Hmm, really?

It's hard to measure objectively... but my perception was always that there
was an explosion of SCMs around the early-mid 2000s, after everybody got sick
of CVS, but eventually Git won out and a lot of the alternatives / diversity
in the space went away.

Within short succession, there was Subversion, Arch, Darcs, Quilt, Bazaar,
Mercurial. On the commercial side, perforce had a certain amount of traction,
and the Linux kernel was using BitKeeper... which no doubt encouraged a lot of
the innovation in the open-source space.

Then, once Git was developed, got huge exposure and traction through the
Kernel, and GitHub came onto the scene, it quickly became dominant - despite
the alternatives, and despite the goofy interface.

~~~
gkya
I firmly believe that GitHub has at least 40% role in git's success. Another
40% is Linus, and the remaining 20% is git's technical merits.

~~~
tacostakohashi
Sounds about right to me... but it's hard to decouple things so neatly. It
wouldn't really be _possible_ to create an SVNHub that worked as well as
github.

~~~
sqrt17
Before everyone got onto GitHub, there was SourceForge and GoogleCode. Both
worked well for a lot of people for quite some while. Also, if you really want
to, you can use the SVN interface of GitHub and never go through git. You
could, in its time, also use Google code with git repositories but without the
pileup if nice little things that make GitHub more than just a git hosting
service

------
stonemetal
Veracity is the only other SCM I know of that takes the distribute everything
approach of Fossil. Are there any others?

~~~
msingle
haven't seen [veracity]([http://veracity-scm.com/](http://veracity-scm.com/))
mentioned in a while! I always thought the idea of using JS as the built in
scripting/templating language was ahead of its time.

~~~
rkeene2
Fossil has TH1 -- pretty much a stripped down Tcl, but can also (optionally)
call out to full Tcl.

------
gglitch
I use Fossil for all my personal projects, and I use its wiki, technotes, and
tickets for almost all of my knowledge and task management. It has become the
centerpiece of my workflow. Where else have I seen as great a combination of
reliability, simplicity, and flexibility? Oh yeah, SQLite. Thanks drh.

------
jjirsa
No/manual rebase sounds awful

~~~
BeetleB
Genuinely curious: Why do you need rebasing?

I'm mostly a mercurial person, where doing a rebase is highly discouraged and
nontrivial. After all these years on mercurial, I've never found a need to do
it. Why is it so popular amongst git users?

~~~
iso-8859-1
If you like a readable commit history, rebase is useful to reorder and squash
unnecessary commits. Some repositories, like Rails have a lot of merge
commits. Why should I have to read through them? Also, all kinds of failed
tests may have been developed in a feature-branch during month-long
development.

Interactive rebasing lets you avoid that mess, I don't think it is that
complicated. Mercurial uses the same underlying data structures, so I don't
understand how rebasing can be more complicated on Mercurial than Git.

~~~
BeetleB
So let's say I branched off of master 3 months ago, and slowly developed the
feature. Now if I rebase, will the commit history show all my local commits at
the time they occurred (i.e. spread across 3 months)? Or will it show up as a
single commit at the end?

As for "reading through them", I usually use a GUI that shows the commit
history, and it will show all the commits in a branch in, well, a branch. I
can easily ignore them.

~~~
jdmichal
Git actually maintains the following:

Author and AuthorDate: These will not change during a rebase. Unless maybe you
do an interactive rebase and edit the commit... I'm not 100% sure how those
interact.

Commit and CommitDate: These will change during a rebase, as a rebase is
recreating the commit and that will be done with the current user and date.

------
marcinkuzminski
It would be great to add Fossil, as another backend to RhodeCode VCSServer
that now supports git, Mercurial and SVN.

It's also written in python so it should be not so hard.

------
wirrbel
Anyone using it for development? What is your experience?

~~~
rbehrends
I'm using it for a number of personal projects and a couple of projects with a
small number of collaborators.

Advantages: The entire repository is a single file (SQLite database), which
makes some things easy (backup, putting it on a USB drive, mailing it to
another person) and has support for tickets and a wiki built-in. It is simple,
but feature-complete for the use cases it is intended for.

Disadvantages: The command line interface is lacking in some regards (which
can be fixed through addon tools, but isn't for everybody). In particular,
there's a huge feature gap between `fossil ui` and `fossil timeline` for
viewing history. Like Git (and unlike Mercurial and Bzr), you're forced to
deal with commit hashes rather than numerical version numbers (which can be an
annoyance when using annotate/blame, for example). Third-party contribution
via `fossil bundle` is too limited IMO; you really want all contributors to
have direct access to the repository to be productive.

~~~
sqrt17
Numerical version numbers in Mercurial are a good thing until they start to
differ in different repository copies, after which you have to educate
everyone to refer to versions by their hash instead of the numeric version

~~~
rbehrends
1\. You can use the Bzr approach instead, which has universally valid revision
numbers.

2\. Even local revision numbering has useful applications, such as
annotate/blame, where numbers (unlike hashes) follow a chronological ordering.
It is still better than not having them at all.

------
pebblexe
I wish it supported AJAX and the client UI was decoupled from the repository.

~~~
lvh
I'm not sure I understand what you mean with "client UI being decoupled from
the repository". Wouldn't everything you do in an SCM necessarily be coupled
to a repository?

~~~
david-given
If you have multiple repositories, you have to set up the UI and ticketing
setup in each one individually. (Although you can share a login database.)

I don't know if it's been fixed by now, but back when I was using Fossil
regularly there were long-standing bugs where pushing the UI and ticket
configuration from one repo to another didn't work properly, so synchronising
look and feel across multiple repositories was hard.

------
ifduyue
Too slow, tried to convert linux git repo to fossil but failed.

------
X86BSD
I absolutely love Fossil. And the author is a great guy! It never gets the
press or usage it deserves. Glad to see this come up on HN!

~~~
dang
It came up on HN not long ago:
[https://news.ycombinator.com/item?id=12673229](https://news.ycombinator.com/item?id=12673229).
Normally we'd bury this one as a duplicate, but the community is clearly
interested in this.

------
alvil
Fossil is running on
[https://www.sqlite.org/docsrc/artifact/c3a749450a2f0d73](https://www.sqlite.org/docsrc/artifact/c3a749450a2f0d73)
.. another lovely piece of software .. like it

------
hubert123
I dont see the point of Fossil, I looked into it. The commands arent that much
easier to understand. If I'm using an SCM anyway and I still need to use a cmd
line and I still need to memorize commands then I might just as well use git.
And Git has Guis now.

~~~
tacostakohashi
Without having looked into the details... I do rather like the idea of an SCM
with a built-in ticketing / documentation (wiki / markdown rendering system).

These are both things that every project ends up needing, but end up with some
different solution, which then ends up with a loose, brittle, custom
integration with the SCM - using your ticket name for branches, but the having
to look up the details on a website - checkin hooks, these kinds of hacks.

It's not too difficult to imagine some simple, robust setup where the ticket
state is and documentation (markdown) is store in the SCM, and you can view it
either using the command-line, or fire up a local webserver embedded in the
scm tool.

~~~
qznc
On the other hand, it does not make much sense for ticketing and documentation
to be distributed. They inherently must be centralized for a project.

~~~
tacostakohashi
I disagree completely - I think these things have the same properties as
source code.

Everybody thought SCM had to be centralized too, until it turned out that it
didn't. I can see the same benefits of making local changes to tickets and
documentation, then sharing those changes later when they're in a good state.

~~~
__david__
You might like
[https://github.com/brandonson/evict](https://github.com/brandonson/evict). I
used to use `ditz` but it was abandoned years ago and was tied to Ruby 1.8 in
a bad way. I've been meaning to switch to evict but haven't ever been able to
get it to compile :-).

~~~
lvh
IIRC, ditz and evict and b-e and ticgit and... all don't solve a problem for
public projects which fossil does: random people on the Internet need to be
able to submit bug reports.

