Why I Use Fossil | Hacker News Reader

Why I Use Fossil

sheddingbikes.com

159 pointstwampss52 comments

While I love the idea of Fossil, I think Zed downplays a lot of the problems that it has in reality.

There's no real way to throw out branches easily, nor is there any rebasing. Fossil doesn't track renames, so if you rename files in a branch, you'll need to rename them again on mainline before the merge. Fossil doesn't have any concept of patch management via email, which is fairly central to most OSS projects I'm involved with. The bug tracker is not DAG-based, but rather last-wins, which can result in some surprising outcomes. You have to log in to see bug reports, which can be discouraging for users, and prevents your bugs from being googleable. And so on.

I'm not saying that GitHub is perfect--hell, I make a competitor, based on Mercurial no less, so I clearly don't think it is--but I think Fossil still has enough fundamental flaws in it that I would be very hesitant to pick it up for a new project. I'd rather deal with GitHub's proprietary system (of which all data is accessible via its API [1]) than deal with Fossil's SCM quirks. Zed clearly disagrees, and has projects where it's working for him, and the SQLite project uses it, so it might work for you. But I would strongly encourage caution. I'll personally be sticking to Mercurial and Git for now.

[1]: http://develop.github.com/

This is load of FUD and you know it. First, your claims are completely from your experience, like email patch management. Only a few projects use that, and most just tell you to put it in a Trac or similar.

Second, all the things about "not being to see X" are configurable. But, then again I can't expect you to actually research a system before you go talking about it, 'cause that'd interfere with your FUD.

Third, rebasing is both a load of crap, and also not as necessary in fossil by design. It has a much more strick auto-commit mode that gets rid of plenty of problems with needing to rebase. In fact, I wish all the SCMs did this optionally.

Finally, it has a bug tracker. Come talk to me when Trac is DAG based.

So, you've demonstrated you know jack squat about fossil, then you come on here and talk like you are some authority on it and "other projects", then say "I would strongly encourage caution." like the world will end.

My only question is: How long did you work at microsoft? :-)

I said that Fossil has no patch-based workflow. You say few projects use it.

I said that it can't rebase. You say that I shouldn't rebase.

I said that the bug tracker was hard to use because it's last-wins, not DAG based, which is a problem for a distributed bug tracker (Trac is not distributed, so it doesn't need to be DAG-based). You respond that Fossil has a bug tracker.

In all these cases, you don't refute my points. You're merely arguing they're immaterial. As such, your accusations of FUD and name-calling seem strange and defensive. You're welcome to contend that Fossil does not need these features, but since many projects and developers that I work with use them heavily, I think it'd make more sense to discuss why they are unnecessary or wrong.

To be fair, not all GitHub data is accessible via the API. Messages, pull requests, comments, wiki pages, and some gist functionality all lack API access.

Edit: I originally said there wasn't API support for issues, but in fact there is.

"You can create branches by doing multiple commits off of the same base version." It doesn't sound hard, but perhaps I am missing something?

I said throwing out branches you don't want is hard. You said creating branches is easy. Those are both true.

No he's full of it. Branches are just tags on leaves. In fact, you can read about it on the website, but of course that'd involve actually trying to understand something first before talking about it.

"Fossil doesn't have any concept of patch management via email, which is fairly central to most OSS projects I'm involved with."

Don't you use 3 sites, one you write that try to optimise away from this ghetto process?

I had a look at your accounts, some of your projects have 0 followers, and your average follower count is around 0.9. You can calculate your average commit and contributor volume on your own, or maybe write that into Kiln.

If your download count just increased to 1, that's because I accidentally clicked between the headings and got a .gz file with an attachment header from the server (wtf?).

I think the most important thing in the original article is the serious point that there are plenty of us out there who have to know and use all of the SCMs and tbh, they aren't really that different. All the ones I use in OSS do one major job: SCM. Even as you put it on your blog "the enemy of git and mercurial" (wtf?) subversion actually does a good job at this. For a long time it was king, too. In fact, I still miss the svn/trac combo, but Zeds point about this being a shit to setup and consuming way too much by way of server and admin resources is spot on the money. Not wanting some commercial venture to host it for you / or not liking their specific feature set is taste, but it won't stop anyone that matters from using your code, or submitting patches.

Man I should never come to HN, clearly.

If I may quickly address Zed's concerns about putting his code on GitHub:

1. GitHub is a node on a distributed graph, you're still in full control of your source and its history thanks to Git. Push your code to a dozen different places, Git doesn't care and neither do we.

2. We have soft disk space limits. If your OS project is massive, we're not going to suddenly start charging you if you exceed that space. We want lots and lots of open source projects on GitHub, we just don't want it to become the place you host your music and porn, there are plenty of other services that are happy to do that.

3. GitHub's growth (thus revenue) skyrocketed during the recession, and it's only getting better. We've rejected acquisition offers since the site was launched, we care deeply about the service we've built.

I think the distribution issue is more about metadata than the code itself: issues, wiki pages, and comments are still centralized on GitHub. With Fossil, I gather, they're distributed among each clone.

We're slowly but surely moving towards having those things either become git-backed or exportable. Wikis are first up and we're very close.

Exportable is not the same thing as naturally distributed though. And git-backed is nice, but with fossil it's fossil-baked as everything is tucked into the exact same repository.

> Wikis are first up and we're very close.

Well yeah but as far as I understand, with Fossil it's done already, not just close (and I'd say distributed bug trackers are closer than wikis if not done already)

Integrating those systems directly into Fossil seems like a poor design decision. Everyone has different requirements and it directs focus away from the core responsibility of a VCS. Do one thing well and all that good stuff.

Yes, if you narrowly define VCS as "shoves code around". If you define it as "versioning the code and related project material" then it's exactly what should be in the tool. In fact, I predict this will be the next iteration of project management tools, where everything is stored and managed in git/hg/mercurial, so the next logical step is what fossil does.

People said that same sort of thing about RoR or Django too. "What?! You have to do it the way they want? I prefer fooORM!", and so on. The point is not that it is great at whatever, the point is it get stuff out of the way at start time, and allow you to get to the meat of it quickly. Later on if the project turns into something interesting, you can switch to redmine, or put a real wiki behind it, and so on (but only as really needed).

That's an interesting point in light of Rails' recent movement towards more modularity. It suggests that there may be room for a Fossil-like abstraction over Git that has (pluggable?) built-in cloned-by-default issues, wiki, etc.

Honestly I've always wondered why redmine, trac, et al don't already build their wiki on top of the vcs anyway, instead of using a separate database with tracking. Such a step seems counter-productive.

I can see arguments both ways. Having the wiki separate means that the repo doesn't get polluted with unrelated commits (especially important for SVN which doesn't have branches), and it makes setup at least somewhat easier, since an extra push-capable user doesn't need to be added.

>> (especially important for SVN which doesn't have branches)

explain.

Subversion doesn't have a built-in notion of branches in the same way that distributed systems do. Instead of being names for nodes in the DAG of commits, branches in Subversion are usually handled by manually maintaining separate versions of the same code in a branches/ subdirectory. In a distributed system, you could keep a wiki or bug database on its own branch, and commits to that branch wouldn't be visible if you only cared about the main branch. In Subversion, those commits would be visible, because it's all part of the same tree.

One caveat: Subversion's branch management may have changed since I last looked (version 1.5 or so). However, systems like Trac and RedMine were designed when branches worked as I described above, so it still serves to explain their rejection of SCM-backed storage.

This is exciting news. masklinn is right that it probably won't entirely address Zed's points, but for people like me who don't care as much that it's baked in, this is very cool.

I think that the concern with #1 was not having one's stuff one somebody else's server. It is that if said server becomes unavailable, there is no alternative left. So if you bet on git, how do you get your nice wikis, bug trackers, HTTP access and whatnot without GitHub?

I think you should know all the SCMs you can and be able to switch between them.

Sometimes I feel like the modern programmer is expected to spend more time learning to use multiple implementations of the same basic concept, than on actual programming.

'tis true though. Imagine how many companies out there looking for specific programming skills:

1) RoR NINJA!

2) jQuery EXPERTS!

3) JSF and/or Spring _and_ Struts2

4) C#, ASP.NET

5) All-things XML (XSLT, XSL-FO, XQuery, Xwhatever)

6) Specifically asking for DB2 or Oracle (not DBA, but for a typical developer position)

Instead of the fundamental programming skills like fundamental Data Structure and Algorithm, fundamental RDBMS, fundamental Software Engineering, etc.

On the other hand, I think Zed is just trying to be sarcastic to those who said that "you must keep on learning new things, like myself, see... I'm learning GIT" when it first came out but flat-out refused learning other things at the same time.

I took a job hiring a RoR ninja and jQuery expert as lead dev (for an alpha app) and immediately rewrote it in Django and MooTools/Google Closure. You can know the trendy stuff but still develop with solid software, provided you have some latitude in technology decisions.

I looked at Fossil a few months ago. I basically liked it, but Fossil (1) didn't do Git-style file rename detection, and (2) didn't have "git add --patch" functionality. Has this changed? I can't really use an SCM without those features anymore.

Forget rename detection; it doesn't do renames period. So if you rename a file in one branch, you need to rename the file in the other branch BEFORE the merge, or you'll simply end up with two different files with different names.

Sigh, bullshit. I do this every day and it's just fine. You must be referring to some other concept of rename in some bizarrely complicated configuration you've worked yourself into.

I am referring to this sequence:

    gozer:~$ fossil new zed.fsl
    project-id: e4549d02538b1b58cf28488f76fc7549dc11a752
    server-id:  0bb5e1159eef42ed514c6ec13d17ba05f21ecdea
    admin-user: benjamin (initial password is "068bda")
    gozer:~$ mkdir zed
    gozer:~$ cd zed
    gozer:~/zed$ fossil open ../zed.fsl 
    gozer:~/zed$ echo hello > hello.txt
    gozer:~/zed$ fossil commit -m "initial"
    fossil: nothing has changed
    gozer:~/zed$ fossil add hello.txt 
    ADDED  hello.txt
    gozer:~/zed$ fossil commit -m "initial"
    New_Version: 10c3840dc611fdc22888571560b908f36e647e59
    gozer:~/zed$ echo zed >> hello.txt 
    gozer:~/zed$ fossil commit -m "edited"
    New_Version: 10aa55193ddd374a75d37508cbc8a09466a05019
    gozer:~/zed$ fossil update 10c384
    UPDATE hello.txt
    gozer:~/zed$ mv hello.txt hello2.txt
    gozer:~/zed$ fossil mv hello.txt hello2.txt
    RENAME hello.txt hello2.txt
    gozer:~/zed$ fossil commit -f -m "renamed"
    New_Version: 3c3253cbd31cbc479c888fb8b1f38a8a46d8d4d6
    **** warning: a fork has occurred *****
    gozer:~/zed$ fossil merge 10aa55
    gozer:~/zed$ ls
    _FOSSIL_       hello2.txt     manifest       manifest.uuid
    gozer:~/zed$ cat hello2.txt 
    hello

And just to go the other direction, since some DVCSes behave differently if their parents are in a different order:

    gozer:~/zed$ fossil update 10aa55
    ADD hello.txt
    REMOVE hello2.txt
    gozer:~/zed$ ls
    _FOSSIL_       hello.txt      manifest       manifest.uuid
    gozer:~/zed$ cat hello.txt 
    hello
    zed
    gozer:~/zed$ fossil merge 3c3253
    ADDED hello2.txt
    DELETE hello.txt
    gozer:~/zed$ cat hello2.txt 
    hello

Contrast this with Mercurial:

    gozer:~$ hg init zedhg
    gozer:~$ cd zedhg
    gozer:~/zedhg$ echo hello > hello.txt
    gozer:~/zedhg$ hg ci -Aminitial
    adding hello.txt
    gozer:~/zedhg$ echo zed >> hello.txt 
    gozer:~/zedhg$ hg ci -medited
    gozer:~/zedhg$ hg up 0
    1 files updated, 0 files merged, 0 files removed, 0 files unresolved
    gozer:~/zedhg$ hg mv hello.txt hello2.txt
    gozer:~/zedhg$ hg addremove -s100
    recording removal of hello.txt as rename to hello2.txt (100% similar)
    gozer:~/zedhg$ hg ci -mrenamed
    created new head
    gozer:~/zedhg$ hg merge
    merging hello2.txt and hell.txt to hello2.txt
    0 files updated, 1 files merged, 0 files removed, 0 files unresolved
    (branch merge, don't forget to commit)
    gozer:~/zedhg$ cat hello2.txt 
    hello
    zed

Git and Bazaar work similarly. This can come up very easily early in a product cycle--doubly so if you have the misfortune of working on a Java project where people are refactoring often.

So, if you want to download and build it, here's the page:

http://www.fossil-scm.org/index.html/doc/tip/www/build.wiki

The prebuilt images are labelled as 'snapshots', and or you can "Select a version of of fossil you want to download" to build from source with no guidance on what version would be a good idea to use.

Maybe everything is stable? Who knows.

Not to be confused with Plan 9's Fossil file system: http://en.wikipedia.org/wiki/Fossil_(file_system)

he gave reasonable arguments, assuming one does always want all of those extra features beyond VCS for each new project. for me, most of the projects i start never need to go public, and of those that do, most don't need a full-blown wiki or issue tracking system. README and TODO file are sufficient 99% of the time, esp with no public collabs. so git and github still hit the sweetspot for me in the default case.

Fossil actually fits this use case better than git or mercurial, because fossil is just a 700 kb executable that you can take with you. No need to install a package or hunt for cygwin versions.

and the whole repository is just a single file. Backing up your whole project and the SCM is a matter of copying two files over.

Git is a swiss army knife for fossil's switch blade.

Fossil has a wiki, issue tracker, etc, all in a small little portable package - it's far more deserving of the 'swiss army knife' label than git. Git's more like an industrial lathe or something.

agreed! I was running low on industrial terminology atm.

> and the whole repository is just a single file

http://keithp.com/blogs/Repository_Formats_Matter/

+1 mostly for an awesome handle

I didn't find his arguments that compelling. User management is something you are going to have to do no matter what VCS you are using Fossil doesn't remove that requirement. Last I checked Fossil didn't magically generate custom CSS and project logos so I am still going to have to do all that stuff with fossil. Pretty much every thing on the if I don't use fossil I will have to do this extra stuff is stuff you have to do for fossil as well.

All this while fossil is relatively untested by comparison. If my project needs something more than a wiki then I stuck doing all the setup and config any way so I might as well use a real wiki and ticketing system.

"User management" in other systems involves either copying ssh keys or using a service like github. If it's Trac you're talking about then depending on the version either you're doing command line operations that make no sense, or maybe you got one of those fancy web admins.

The point was, fossil has a nice flexibly but easy to use integrated user management. I can go in and say that anonymous users can post tickets or not, commit or not, clone or not, all fine grain. I haven't ran into a single system that does this nor does it this easily.

> Last I checked Fossil didn't magically generate custom CSS and project logos so I am still going to have to do all that stuff with fossil

I believe you really don't want to do that though, last time I checked Fossil generated HTML from C, either directly or getting it out of the sqlite db.

We've been using git and github for a few months now, and it's not intuitive, nor does it get out the way or offer to help to figure out what just happened. I'm fairly sure that with time we'll get used to the common use-cases, but right now I'm still backing up the 'src' dir before doing a 'git rebase'.

It looks like it's here to stay, so I'm hoping someone will make a set of standard wrappers/GUI for making git bearable.

Check out http://progit.org. It's awesome, and will teach you everything you need to know about git.

I think it's interesting that Zed considers Github/Bitbucket weaknesses. What most open-source projects need more than self-hosting is contributors.

Portability is great but I'd rather have a project that I'm working with other people.

I hadn't really heard of Fossil, so I went to read this post.

The one thing I really, really didn't give a damn about as I went to read a post like this was how everyone who doesn't like Fossil is merely a lazy, ignorant goon.

Whatever. I know bloggers like to gin up pointless arguments for the sake of controversy, but I don't give a shit about that sort of vapidity.

A sampling of the Fossil code. This is the source browser code. http://www.fossil-scm.org/index.html/artifact?name=23a693054...

C based webapps... lean, mean and blazing fast. And a little masochistic to code.

Ugh.

Zed, like drh miss the point yet again because they are closed minded programmers and keep on forgetting that people who are not programmers may end up using fossil as they wish to contribute a ticket or documentation to a project running on fossil, but get reluctant dealing with the crappy UI or the fact that they have to learn to do markup. It's also clear that drh really isn't interested in anybody else but his needs.

Git has Junio Hamano who made it usable and practical to people who weren't Linus. Who's this hero in Fossil? Well, it looks like the mailing list is still waiting for them to arrive.

It is a program for programmers by a programmer. And Fossil is a VCS first and and SCM second.

The beauty of git lies in what it does and that is managing code. The same is true of fossil. DRH is known for making sqlite and in turn fossil rock solid, and easy to program against. THAT is a far better feature and interface than some UI nitpicking you might throw at it.

Just because lots of your buddies use it, doesn't make it useable. Git approaches the useability of iptables, which is to say, utterly unusable unless you have the manpage tattooed on you arm.

When I was evaluating Fossil about 1 year ago, compared to git and mercurial -- one of the requirements for my company was that it support large files. All of them supported large repositories, but easily ran into issues at about 10 MB for git and mercurial. Large file support for mercurial could be patched or extended but not in an ideal fashion. Fossil was able to handle files up to about 700 MBs in my tests before puking. I should add, those weren't binary files -- but large XML files.

Instead of a per-project-trac you could setup redmine which supports multiple projects (tickets, wiki, forum, repo). Fossil looks interesting but I wouldn't want to pass on git.

Or MantisBT, if you don't like managing Python/Rails processes. With plugins, MantisBT can not only support multiple projects, but integrating multiple repositories of multiple VCS types. I ran a single install at my last job with many repos of three different source control types (Git, SVN, and an in-house SCM built on SCCS).

Here here. Redmine is sweet, though the support can be a little slow on the forums.

That said, it has great issue tracking, issue conversations, multiple SCM repo integration, wikis, news, forums, etc.

Reply on news.ycombinator.com