Fossil

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

by tosh • 6 years ago

250 109 6 years ago

dkulchenko• 6 years ago

Notably used (and developed) by the SQLite authors. They explain their rationale here: https://sqlite.org/whynotgit.html

kipari• 6 years ago

I enjoy how well-crafted Fossil seems to be; just like SQLite, which a sibling comment also mentioned. I really want to use Fossil, but it would be way too hard for me to not have the index/staging area of Git. [1] For all the software that claims to be 'opinionated', Fossil really is that.

[1] https://fossil-scm.org/home/doc/trunk/www/gitusers.md

Arnavion4• 6 years ago

Yes. I use `git add -p` and `git stash -p` all the time and couldn't work without them. Fossil's equivalents appear to let you specify a subset of files to commit / stash, but not individual thunks inside them. [1] [2]

Not to mention the lack of `rebase -i` to clean up local commits.

[1] https://www.fossil-scm.org/fossil/help?cmd=commit [2]: https://www.fossil-scm.org/fossil/help?cmd=stash

rstupek2• 6 years ago

It would seem the authors consider rebase harmful: https://fossil-scm.org/home/doc/trunk/www/rebaseharm.md

JoshTriplett2• 6 years ago

Agreed. I'd love to have integrated bug-tracking, and some of the other features, but Fossil is also trying to drive particular opinions about version control that are incompatible with how many people want to work.

It's already hard to move people away from a system that has huge network effects. This makes it much harder.

beagle3• 6 years ago

There are several bug tracking systems that store their data inside the repository (and as a result, branch / merge / push / pull automatically) -- including the venerable "vi bugs.txt" system which works surprisingly well from experience.

What fossil brings that those systems don't is indeed the network effect as you pointed out. It's integrated with the web frontend, and is thus used by everyone using fossil and fossil's bug tracking, based on experience with cvstrac, is low ceremony, easy to use and reasonably effective -- even more than "vi bugs.txt" which sets a remarkably low ceremony bar.

richie_adler• 6 years ago

Where did you see opinions in that document? It's a technical description of the functional differences between Fossil and Git, explained with Git terminology.

dognotdog• 6 years ago

I'm a big fan of Fossil, but I've sadly not used it in a while for new projects, as when stuff has to go on gitlab or github it is just too inconvenient.

Even though one-way pushes to github/gitlab via --fast-export / --fast-import are relatively painless, going the other way for contributions is still not easy because of rebase issues, etc, at least to my knowledge.

dfischer• 6 years ago

Can anyone give a conceptual model breakdown of the data model of fossil vs git and trade offs? I’ve been quite interested in these types of structures. I need to play more with them.

cbsks• 6 years ago

These web pages give a good broad overview of Git vs Fossil. They don't go into much detail about the internals, however.

Fossil Versus Git: https://fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wik...

Why SQLite Does Not Use Git: https://sqlite.org/whynotgit.html

Hints For Users With Prior Git Experience: https://fossil-scm.org/home/doc/trunk/www/gitusers.md

aidenn08• 6 years ago

The first item on "why sqlite does not use git" asking for a timeline view. That looks almost exactly what "gitk" shows, which was builtin to git before github or gitlab existed.

A quick scan of the other items are all more-or-less true so it's a shame it leads with that.

Midar5• 6 years ago

I'm using it for a while now for https://objfw.nil.im/ and am quite happy with it. I wrote a little bit about that at https://blog.nil.im/?78.

It's quite sad to see that so few projects use it. The idea of having everything in one repo, incl. bugs, is just great. I can create new bugs while offline, update bugs while offline, etc. and then just sync everything once I'm back online.

It also has pretty good support for incrementally importing from and exporting to Git: https://blog.nil.im/?79

kzrdude• 6 years ago

Practical aspects aside, having issue tracking in the repo prevents lock-in of that data - in the way that the github platform works, for example.

Midar5• 6 years ago

This is exactly what intrigued me and made me switch to Fossil. I don't want to have my issues, wiki etc. held hostage by some company. And if someone wants to fork it, they should be able to fork it including issues and wiki.

ncmncm5• 6 years ago

I was astonished and appalled to find that your Github bugs, wiki, and PRs were not all in your repo.

nix233• 6 years ago

I use fossil mostly as a Customer/Project KB/Documentation tool, when a new project starts i have all the documentation, code snippets/examples in one single file, when the project is finished, i have to give one sqlite.db file over to the customer and that's it. LOVE IT, a really great tool!

OldHand2018• 6 years ago

Thank you for posting a link to your site. It's really nice to see a live demonstration of Fossil. I notice that your page is using https - does Fossil do that or do you have something else in between (nginx, etc) that provides the https?

Midar5• 6 years ago

Yeah, I'm just running `fossil server --scgi` in a chroot and then use nginx for TLS.

wyoung28• 6 years ago

Crypto is something best delegated to others. There are a bunch of ways to host Fossil, several of which offer HTTPS proxying: https://www.fossil-scm.org/home/doc/trunk/www/server/index.h...

sgbeal• 6 years ago

Another option is running is behind Apache as a CGI, and let Apache handle the HTTPS part. My repos (fossil.wanderinghorse.net) all run as CGIs on a $7/month shared hoster, and have been since 2008, without issues.

thunderbong• 6 years ago

This is really nice. How have you been hosting this? How well is fossil able to handle the traffic?

I've read so many articles about the advantages of static site generators and serverless implementations for blogs so that they are able to handle traffic and the insane amount of tooling around each of those concepts. It's so great to see a well crafted piece of software being able to take care of all that so seamlessly.

I'm a big fan of fossil personally and use it for all my projects as well as for all the projects in our organization.

Midar5• 6 years ago

This is running on a server with super slow single core performance and slow I/O (Sun Fire T1000 with full disk encryption, giving ~ 2 MB/s for the disk), and yet it feels fast and I've never encountered any performance issues. As long as your repo is not as gigantic as https://pkgsrc.fossil.netbsd.org, you'll be fine, no matter what slow hardware you throw at it.

wyoung28• 6 years ago

A lot of us Fossil users host it on $5 VPSes. It's written in C atop SQLite, so the network is almost always the bottleneck, not the server-side processing speed.

sqlite.org and all of the other repos D. Richard Hipp maintains (Fossil, Pikchr, the separate SQLite docs repo, the forums for Fossil and SQLite...) all run on a $40/month VPS. The page generation time is calculated and displayed at the bottom of non-static pages like this one: https://sqlite.org/src/

Quekid53• 6 years ago

The idea of having everything in one repo, incl. bugs, is just great. I can create new bugs while offline, update bugs while offline, etc. and then just sync everything once I'm back online.

The bug thing I kinda disagree with... or at least I'm skeptical, shall we say. Bugs are solved when the fix has been deployed and verified fixed in production, not when someone commits/pushes/merges a potential fix to the main branch. Sure you can separate the 'bug-X fixed' change to the bug tracker and the code commits, but then what have you gained over just a 'Fixes: X' annotation in the commit msg?

This could be misunderstanding on my part about the intent/process around bug/issue handling in Fossil, so I'd appreciate if you could expand on what you like about and how it works within the larger 'deploy a fix' context.

(I tried Fossil for a bit on a very small scale -- it was pleasant enough, but ultimately Git's network effects win out big time... at least for me.)

lrem• 6 years ago

It isn't putting your issue tracking into an equivalent of a git repository. It just contains a rather standard-looking issue tracker, along a wiki for documentation, in the same sqlite. And they are distributed/synchronized just like the repository.

Midar5• 6 years ago

That is only true for projects where you need to deploy. In that case, yeah, you of course can only close the bug once you fixed production. But for normal software development, you can fix the bug in the software and you can update the bug tracker, and then push everything once you're back online.

For example, on a flight, I can look at the bug tracker (since it's part of the clone), pick a bug I want to work on, create a few commits to fix it, then update that bug (set it to closed, reference the commits that fixed it), and then upload it all when the plane landed again.

marmaduke2• 6 years ago

I wanted to use Fossil but the division between what you do in CLI and what you do in the web UI was too arbitrary. I wanted to edit the wiki in vim, for example. Now I don’t care anymore and just use Git and GitHub

gw• 6 years ago

Yeah it's a bit bifurcated. Internally there's a lot of coupling -- HTML embedded directly in the C code and whatnot. This could be resolved if tools could be built on top of fossil, but the CLI code uses `exit` everywhere which makes it impossible to use as a library. I think they made an incomplete attempt at a JSON API, but what you really need is a proper linkable library like libgit2.

bachmeier3• 6 years ago

Maybe I'm not understanding, but it's pretty easy to edit the wiki from the command line in vim (I've used text editors for it before).

https://fossil-scm.org/home/help?cmd=wiki

To edit a page, do an export and then a commit when you're done. It was easy enough to add this as a menu item in Emacs.

fossil wiki export foo.wiki foo.md

fossil wiki commit foo.wiki foo.md

wyoung28• 6 years ago

You don't even need the temporary files:

    $ vim
    ...write, write, write...
    :w !fossil wiki create "The Foo Article" -
    :q!

Later:

    $ vim
    :r !fossil wiki export "The Foo Article" -
    ...write, write, write some more...
    :w !fossil wiki commit "The Foo Article" -

Wrapping all of that up into Vim macros would be a small matter for someone sufficiently interested.

Also, someone wanting to edit wiki-like docs in a text editor rather than in the web UI is probably going to find Fossil's embedded docs feature more useful anyway: https://fossil-scm.org/home/doc/trunk/www/embeddeddoc.wiki

marmaduke2• 6 years ago

Good catch! I really did look for this when I tried to use it years back.

sigzero2• 6 years ago

Gitea falls into a similar category

[1] https://gitea.io

ComputerGuru• 6 years ago

No, it really doesn't. Gitea is just your typical web stack built around forking git.exe processes.

ncmncm5• 6 years ago

And, in particular, it doesn't put the bug tickets in the repository. I was disappointed to learn that.

kayson• 6 years ago

Reading through some of the articles linked in the comments, I'm very hesitant to use something whose creator is so opinionated and vocally against another piece of software. Maybe its just the style of writing, and isn't actually reflected in Fossil's development, but this kind of attitude doesn't inspire confidence.

bachmeier3• 6 years ago

It's more that "why don't you use Github for sqlite" comes up six times a day, so at a certain point you have to explain why you use your own version control system. A lot of developers today know nothing other than Git and assume anything else is wrong by default.

mghsm• 6 years ago

Not only that, but they spam the Fossil forum with request to make Fossil more like Git, even if they don't personally use Fossil, because they seem to be unable to accept the fact that Fossil exists and drh has making the decisions that he thought best for the software.

wyoung28• 6 years ago

The whole point of those articles is to compare and contrast.

bachmeier3• 6 years ago

Aside from standard version control uses, I eventually realized that the tickets database is just a regular sqlite database that lets you edit the schema and query any way you like. What's really cool is that it's version controlled. You can put any information you want into the tickets database and then pull changes like any other repo. You can view the timeline to see all the changes you've made to the database over time.

michaelmure2• 6 years ago

If you like this idea of embedding a bug-tracker (and eventually the code review) within a DVCS, I'm working on a project[1] that does that for git.

[1] https://github.com/MichaelMure/git-bug

cortesi• 6 years ago

Whoa. Many, many years ago I started idly hacking on a similar project with similar ideas and an identical name. I've always intended to return to it in my Copious Spare Time, which of course means I never did and probably never will.

When I started exploring this I registered the gitbug.org domain - would you be interested in using it for your project?

michaelmure2• 6 years ago

Haha, that's awesome. It's interaction like these (and pretty much this whole thread) that make me think that there is value in this idea. It just has to reach some completion with a good UX ...

I have a bunch of git-bug.tld domains so I guess I'm all set already?

I'd be curious to see your project. Maybe there is a good idea in there? In any case, you are very welcome to join the party.

rkeene22• 6 years ago

I run ChiselApp.com to support publicly hosted Fossil repositories.

The architecture behind it is pretty simple, since Fossil is doing all the work and I'm just orchestrating it (although I do allow you to execute arbitrary Tcl scripts as part of it, so there is some work that goes into the sandbox).

lactobacillis2• 6 years ago

Quick question. Is the entire thing on one SQLite db?

rkeene22• 6 years ago

Each Fossil repository is its own SQLite database. Additionally, there's an SQLite database which holds ChiselApp.com user information (which is unrelated to Fossil information).

samatman2• 6 years ago

I have great fondness for Fossil, used it a couple of times and wish it were possible to keep using it.

I tried to rally some interest on the mailing list behind separating the working parts from the UI chrome into a 'libfossil', which could be integrated into other programs. The verdict was that D. Richard Hipp doesn't really want to, since it's a classic C monolith where the allocation strategy doesn't make that separation easy. Someone started the job, but had to abandon it due to RSI issues.

I still kinda hope someone bites the bullet, because a "libsqlite for versioning" would be a real boon for application developers. Even for fossil's central use case as a code VCS, the monolithic bundling of everything into one program is a mixed bag.

n3k52• 6 years ago

Fossil also supports bug tracking, wiki, forum, and technotes

That sounds great, but I'm scared of checking these features out because I'm currently looking at the quick start guide[0] and am immediately put off by how awful the CSS is. Formatting running text such that a single line can be ~500 characters wide[1] results in very low readability. There's a difference between ‘themeable’ and ‘configuring a custom theme is mandatory because the default option makes you feel sick’.

In case someone working on Fossil sees this: I just bookmarked the site because the project seems very attractive in most other respects. I hope that when I eventually re-visit that link, I'll be able to go on a significantly deeper dive. A somewhat sane style sheet would certainly help.

[0] https://www.fossil-scm.org/home/doc/trunk/www/quickstart.wik... [1] https://i.paste.pics/A9RQ8.png

z2210558• 6 years ago

It looks totally fine to me (lines are wrapping normally). Are you sure it's not something to do with your own browser?

t0astbread3• 6 years ago

I think the complaint was that lines aren't capped somewhere at 70-80 characters but rather fill the entire remaining space in the viewport which can make the text hard to read.

flohofwoe• 6 years ago

Not sure what you're complaining about, the page looks fine in a desktop browser window, the text automatically overflows when the window is resized.

leafmeal• 6 years ago

I agree this can be annoying when you have really large windows, but personally I don't mind it. I don't think it's hard to resize a window, and I _have_ been frustrated when sites (like the new Reddit) force a narrow window when sometimes you need to see more at once.

zzo38computer2• 6 years ago

I agree with you about this.

cnst• 6 years ago

Wait, are you seriously complaining that they don't define an arbitrary max-width, or, even worse, an outright width, in their CSS?!

BareNakedCoder3• 6 years ago

Switch to the Blaze builtin skin/theme for a page with reasonable max-width.

Jach• 6 years ago

...very low readability

Citation needed, especially when the literature doesn't support such a statement. See https://twitter.com/danluu/status/1115707741102727168

chillfox• 6 years ago

maybe just use a smaller browser window?

aarchi• 6 years ago

Has anyone used Darcs [0]? Its design based around a patch theory [1] looks very compelling to me, but I haven't tried it myself.

[0] http://darcs.net/ [1]: https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theo...

lelf• 6 years ago

Yes. It's pretty good actually. It got a reputation for being painfully slow. No longer the case, yet… reputation is reputation.

There's a more modern reincarnation of the similar ideas — https://pijul.org. Ready for playing with, not much else.

7kmph• 6 years ago

Would like to see a SCM that:

- handles large files effectively (build artifacts, 10-40GiBs each, and other binary dependencies)

- partial checkout of the repo/view

- git style operations (have stage area, can stage parts of a file, can stash changes and reapply later, cherry pick)

- can view the history of an individual file (support file relocation)

- access control on individual files, and partial review of the repository (views are "granted" to developers)

- good tooling

- immutable when it makes sense (e.g. you cannot changed a published commit)

- works offline (if possible)

- large mono repo

I evaluated git annex and git lfs, and finally chosen Perforce, mainly for its large file handling, view for each developer and ACL, but the lack of flexibility makes me don't want to commit, and every time I do a merge, I say to myself, "uuh, this again". The other thing it lacks is the "ease of mind", with git, everything is checksummed, if the content changes, it will be noticed by git, with Perforce, you have to tell it you want to edit it. (Not nit-picking on Perforce, I actually think Perforce is a good software, its server runs flawlessly, and have a good p4v (if you don't mind the friction), I think it just lacks good tooling and git style operations)

dilap• 6 years ago

good summary of areas of where git falls short.

i'm curious if the above are compatible with a patch-based VCS. if so, maybe good areas for would-be future VCSs to focus on, to establish a niche...

qznc• 6 years ago

Did you compare Subversion and PlasticSCM?

zegerjan• 6 years ago

Partial clone is currently support at least by both GitHub and GitLab. While still maturing, you could filter for example all large blobs for local development, or only fetch certain sub trees. See also the Git docs: https://git-scm.com/docs/partial-clone, or GitLabs docs: https://docs.gitlab.com/ee/topics/git/partial_clone.html

GitLab will continue to make investments in it for at least the next year as it's a big issue especially for gaming companies.

Full disclosure, currently a GitLab employee.

nix233• 6 years ago

Have a look at Bitkeeper, it's my main SCM (if i don't have to use git).

http://www.bitkeeper.org/

EDIT: But Perforce is nice too, and free for up to 5 devs.

BareNakedCoder3• 6 years ago

Coming soon https://www.fossilarium.com which will have friendlier docs.

noxer• 6 years ago

I would "Join the wait list" but it just opens a page with something my browser blocks immediately because it side-loads some frame from google. A simple HTML form to summit an email really cant be that hard that it needs to be outsourced to google.

BareNakedCoder3• 6 years ago

Apologies. Launched just 2 days ago as a static site on Netlify. Will add a JAMstack-based form once our api backend server is up and running. Google Forms was a quick and dirty solution that let us deploy something now. Fossil on HN is rare so I prematurely jumped at the chance of a mention.

siddharthgoel88• 6 years ago

About 3 years back I was having a discussion with my CTO and he was mentioning why he likes `hg` instead of `git` and that how he uses hg-git bridge to handle git repositories and all. But still he supported the git as the organization wide adopted SCM tooling. Reason being that when we have to choose a tooling which needs to be used by a lot of people in organization then we also need to consider about the learning curve and adoption of a tool. Git is already a default tooling and so many engineers are already familiar with it that choosing it came natural. Moreover, the SCM use-cases for us were mostly the regular standard one.

Over time, I have started to think in terms of innovation tokens [1]. You cannot choose all the new technologies all the time and you have to measure how many innovation tokens would you like to spend on what.

[1] http://boringtechnology.club/

dimator• 6 years ago

Hg's developer ergonomics are just way nicer than git. I tried the hg-git bridge at my current job, but the bridge becomes unusably slow for large git repos.

severak_cz• 6 years ago

fossil has much better command line experience than git. I used this in the past for my solo project but abandoned it because virtually everyone uses git these days.

I even created git wrapper somewhat by fossil command line, but it's not finished - https://github.com/severak/ginger

zzo38computer2• 6 years ago

I use Fossil myself; it is much less confusing than git. (You can even import/export git if you need to mirror it on Github or if another user prefers to use git instead of Fossil.) However, I do not use the forum feature since I prefer to use NNTP for that instead (although Fossil does provide some of the same benefits, and I might use it if it could be used together with NNTP). I do use the Fossil wiki though. It is indeed good that the bug report system can be used without an internet connection, and also that the repository is just a SQLite database file; there are clear benefits to this.

Fossil

Related Stories