Let me be clear
Over the past few years git has become wildly popular, which is great. Git is bringing DVCS goodness to the masses and that is a good thing. It is frustrating when much of the documentation for things like MVC web frameworks and Configuration Management systems assume that you'll be using git for version control as if it's the only logical option, but hey what can you do? In short I like git and tend to recommend it in professional situations when there isn't already a DVCS in place. In part, this is because of the community and ease with which one can get support.
My dad can beat up your dad
Zed Shaw did a great post some time ago about why he uses fossil. The essence of my position is pretty similar to his: It's about yak shaving (you should really read his post). Here's a quick run down of why I use fossil over git/github and hell, we'll throw in mercurial too.
- Single (small) executable file - Fossil is self-contained and compact. It's one file that handles everything unlike git which requires perl or mercurial which requires python. Fossil is so compact that it's been run on embedded systems, routers and phones.
- Batteries included - All by itself the fossil executable includes multi-user access control, a web server, a wiki, a blog/news feed, and a ticketing system/issue tracker. With git and mercurial you need to cobble together a bunch of other pieces of software to get any where near that much functionality.
- I control it - Anyone remember SourceForge? Github is great as long as your needs line up with theirs. Personally I don't put much stock in the idea that our concerns are congruent or compatible. I may be wrong. My fossil setup is run on my servers and I don't have to worry about the interests of a company in which I have no say.
- One file repos - With git and mercurial your 'repo' is a working directory containing a .git or .hg subdirectory with all of the sauce to make your repository an actual repository. With fossil you have a single SQLite3 database as your repository. This means that moving the repo around is as simple as copying one file. There's no more permission hell from multiple people committing locally and no need to repack.
- Multiple working directories - With Fossil you can have multiple peer checkouts from one repository at a time, which is very useful for myriad workflows. Imagine a configuration management system where you have testing, staging, and prod as branches and live directories. You can make updates to one or more working directories and push them without needing to either commit, check-in, switch branches, and then check-out or clone the repository twice which would present a merging/push/pull headache and take up space unnecessarily as with git and mercurial each clone has the full history of changes.
- Simple sync'ing over http(s) - This was a clincher for me. Git sync'ing over http is not elegant and requires much hoop jumping. Having SSH as the only reasonable mechanism for push/pull operations is just not working for me when I have to be on different networks with different policies about what services are or are not accessible. Often SSH is blocked while HTTPS rarely is. Even if forced to use a proxy fossil still works.
Maybe the above list doesn't hold any weight for you. That's ok. I'm not trying to tell you to not use your preferred tool for version control. I like fossil because it does the above with minimal effort on my part. Your needs may differ.
Not much that I can add, but I agree on almost everything.
ReplyDeleteMy only complaint would be that Fossil's ssh code is very system-dependent, and not very incomplete. (sometimes fails to sync, has problems when anonymous+nobody lack privs, has problems on *csh shells)
However, none of this really matters since as you noted, Fossil has excellent http/https support. I get around the issue by hosting my fossil repositories in lighttpd, which is tunneled via ssh, thus getting me the best of both worlds.
Haha, GNUb, never heard that before.
ReplyDeleteTo me, fossil is a bit of everything. You have a wiki, but it's not as easy to use as a markdown based wiki and not as comprehensive as full wiki software. You get a bugtracker, but it cannot compete with full featured bug trackers such as trac. The synchronization mechanism supports HTTP, which is usually mentioned as a plus point. The minus point is it ONLY supports HTTP properly. No "mtn serve" or git via ssh (as Tim mentions, there is ssh support, in theory, but it is system dependent to the extend of making it useless). Also, there is an user+authentication system, but it cannot, for instance, issue permissions for individual wiki pages (internal name/phone number lists e.g.), nor does it support authentication mechanisms other than username/password & cookies.
While comment this may sound very critical, for my personal requirements most of these restrictions do not apply or can be worked around rather easily - so fossil is my RCS of choice too. :-)
SSH support and the speed of handling large files could be improved greatly, though.
Roman, thanks for keeping me honest. You're absolutely right and raise great points.
DeleteThe "I control it" point is not really relevant, since almost all VCSs can be privately hosted. Github isn't a part of Git, nor is it at all required to use Git.
ReplyDeleteNot relevant? I disagree. I'm talking about "...why I use fossil over git/Github …". The fact that I control my fossil hosting is absolutely relevant in that context. Yes one can use git sans github. As the first protestation, when I let someone know that I'm not using git for a project, tends to relate to the fact that "...everyone uses github…", I chose to address them both. I state as much in my introduction.
DeleteHrmmm.. seems relevant to me…
It's not relevant because you can easily host your own instance of git if you wanted. You would once again control it to your heart's desire. You could easily flip that around. There is very little choice in companies offering the same level of hosting as github for fossil. While hosted git solutions are easy to come by. Wether you want a hosted solution or your own control both systems are fully capable of offering that.
DeleteFossil is easier to setup than git however with ease typically comes lack of options.
We use fossil at my employer, and I wish we didn't. It doesn't have the ability to integrate with build/automated test systems. Sure, you could develop them yourself, but that's not really the point.
The ticket system is poorly suited to agile development methods. Again no real option to integrate with better solutions. No ability to have dependent tickets.
Here's are real basic one. You can't force the developer to tie a checkin to a ticket.
I have a really long list of shortcomings of fossil. Outside the office I use git typically if not other systems. It may take a little work to make them far superior to fossil, but it takes a lot more work to get fossil to even compete because of how "self contained" it is.
Oh jeez. you people…
DeleteTelling me that something I wrote in a list of "why I don’t use xyz" isn’t relevant requires considerable gaul. 1) I wrote the f’ing list so it’s relevant to me 2) if you actually understood what I was saying then you’d see it’s relevant to the point that I’m making 3) I loathe falsely assertive language. You can assert that my words aren’t relevant without any knowledge or analysis of _why_ they are relevant enough for me to have taken the time to put them down in the first place. This is the type of thing that people do all the time and it really pisses me off.
So let’s get this out of the way:
1) It _is_ relevant. I don’t have to explain why. You can disagree if you want but the way to do that in a non-offensive way is: “hey I don’t agree with xyz” or “I don’t see how xyz is really relevant because….”. This is 3rd grader shit but since you choose to behave in congruence with what is expected of the marginally literate I will deal with you in kind.
2) Here’s that explanation that I don’t have to give to the adults who read the post: The list is preceded with the text "Here's a quick run down of why I use fossil over git/github and hell, we'll throw in mercurial too.”. If you weren’t acting as a myopic ignoramus you’d understand that the point is particularly relevant to why I use fossil over github and not so much the others (git and mercurial). Also, I open the post by explaining that it was prompted by people asking me why “...I don’t use git and/or github religiously.” I don’t use github religiously because I don’t control it. I fail to see how any person with enough synapses to rub together to manage the process of excreting waste would conclude that such a point is not relevant given the context.
I have no problem with those who disagree with me. I loathe those who declaratively assert falsehoods as though they are fact. Learn how to communicate and we can have a conversation. Keep acting like a bratty kid and you can take your ball and go sit in the sandbox