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 ) 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.
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 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.
Edit: I originally said there wasn't API support for issues, but in fact there is.
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.
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.
> 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)
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.
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.
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.
gozer:~$ fossil new zed.fsl
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
gozer:~/zed$ fossil commit -m "initial"
gozer:~/zed$ echo zed >> hello.txt
gozer:~/zed$ fossil commit -m "edited"
gozer:~/zed$ fossil update 10c384
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"
**** warning: a fork has occurred *****
gozer:~/zed$ fossil merge 10aa55
_FOSSIL_ hello2.txt manifest manifest.uuid
gozer:~/zed$ cat hello2.txt
gozer:~/zed$ fossil update 10aa55
_FOSSIL_ hello.txt manifest manifest.uuid
gozer:~/zed$ cat hello.txt
gozer:~/zed$ fossil merge 3c3253
gozer:~/zed$ cat hello2.txt
gozer:~$ hg init zedhg
gozer:~$ cd zedhg
gozer:~/zedhg$ echo hello > hello.txt
gozer:~/zedhg$ hg ci -Aminitial
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
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.
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.
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.
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.
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.
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.
Portability is great but I'd rather have a project that I'm working with other people.
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.
C based webapps... lean, mean and blazing fast. And a little masochistic to code.
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.
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.
That said, it has great issue tracking, issue conversations, multiple SCM repo integration, wikis, news, forums, etc.