4 ms·

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 t

by gecko 16y 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/ http://develop.github.com/

Goosey 16y 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?
- gecko 16y ago
  I said throwing out branches you don't want is hard. You said creating branches is easy. Those are both true.
- zedshaw 16y 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.
nex3 16y 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.
zedshaw 16y 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? :-)
- gecko 16y 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 16y 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.
fffffffffffffg 16y ago
If you actually cared about being responsible for your own data you'd see that Github is a not a competitor with Fossil in anyway. It doesn't offer the feature of you being responsible for your own data, it doesn't allow you host your wiki, bugtracker offsite in a DAG like you ask. It doesn't allow you to be responsible for your data. This is why github and fossil are worlds apart. Fossil is a product. Github is a service. Here are more distributed issue trackers and these are PRODUCTS not SERVICES: http://lwn.net/Articles/281849/ http://lwn.net/Articles/281849/ http://www.ditrack.org/ http://www.ditrack.org/ Subversion based multi headed issue tracker http://www.distract.wellquite.org/ http://www.distract.wellquite.org/ - A web browser based interface one http://ditz.rubyforge.org/ http://ditz.rubyforge.org/ Distributed issue tracker Something comparable with Github would be gitorious. http://www.gitorious.com/ http://www.gitorious.com/

by gecko 16y ago

Goosey 16y 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?

gecko 16y ago
I said throwing out branches you don't want is hard. You said creating branches is easy. Those are both true.
zedshaw 16y 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.

nex3 16y 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.

zedshaw 16y 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? :-)

gecko 16y 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 16y 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.

fffffffffffffg 16y ago

If you actually cared about being responsible for your own data you'd see that Github is a not a competitor with Fossil in anyway. It doesn't offer the feature of you being responsible for your own data, it doesn't allow you host your wiki, bugtracker offsite in a DAG like you ask. It doesn't allow you to be responsible for your data. This is why github and fossil are worlds apart. Fossil is a product. Github is a service. Here are more distributed issue trackers and these are PRODUCTS not SERVICES: http://lwn.net/Articles/281849/ http://lwn.net/Articles/281849/ http://www.ditrack.org/ http://www.ditrack.org/ Subversion based multi headed issue tracker http://www.distract.wellquite.org/ http://www.distract.wellquite.org/ - A web browser based interface one http://ditz.rubyforge.org/ http://ditz.rubyforge.org/ Distributed issue tracker Something comparable with Github would be gitorious. http://www.gitorious.com/ http://www.gitorious.com/