Why I Use Fossil

http://sheddingbikes.com/posts/1276624594.html

by twampss • 16 years ago

159 52 16 years ago

jf• 16 years ago

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

mkramlich• 16 years ago

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.

FraaJad3• 16 years ago

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.

mattculbreth• 16 years ago

+1 mostly for an awesome handle

jfager• 16 years ago

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.

wingo• 16 years ago

> and the whole repository is just a single file

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

stonemetal• 16 years ago

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.

masklinn2• 16 years ago

> 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.

zedshaw5• 16 years ago

"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.

pjhyett3• 16 years ago

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.

nex36• 16 years ago

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.

pjhyett3• 16 years ago

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.

Tichy• 16 years ago

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?

gcv• 16 years ago

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.

gecko5• 16 years ago

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.

zedshaw5• 16 years ago

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.

johnsea• 16 years ago

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.

nuclear_eclipse• 16 years ago

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).

aagha• 16 years ago

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.

trainwreckin• 16 years ago

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.

FraaJad3• 16 years ago

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.

mml• 16 years ago

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.

bensummers• 16 years ago

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.

Maro• 16 years ago

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.

steveklabnik• 16 years ago

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

abstractbill• 16 years ago

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.

hello_moto• 16 years ago

'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.

erlanger• 16 years ago

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.

gecko5• 16 years ago

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/

Goosey• 16 years ago

"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?

gecko5• 16 years ago

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

zedshaw5• 16 years ago

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.

nex36• 16 years ago

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.

zedshaw5• 16 years ago

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? :-)

gecko5• 16 years ago

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.

raggi• 16 years ago

"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.

experimentor• 16 years ago

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.

sh1mmer• 16 years ago

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.

Semiapies• 16 years ago

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.

torial• 16 years ago

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.

Why I Use Fossil

Related Stories