14 ms·

Why I Use Fossil

159 points by twampss 16y ago

jf 16y ago
Not to be confused with Plan 9's Fossil file system: http://en.wikipedia.org/wiki/Fossil_(file_system) http://en.wikipedia.org/wiki/Fossil_(file_system)
mkramlich 16y 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.
- FraaJad 16y 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 16y ago
    +1 mostly for an awesome handle
  - jfager 16y 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.
    - FraaJad 16y ago
      agreed! I was running low on industrial terminology atm.
  - wingo 16y ago
    > and the whole repository is just a single file http://keithp.com/blogs/Repository_Formats_Matter/ http://keithp.com/blogs/Repository_Formats_Matter/
- stonemetal 16y 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.
  - masklinn 16y 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.
  - zedshaw 16y 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.
pjhyett 16y 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.
- nex3 16y 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.
  - pjhyett 16y 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.
    - masklinn 16y ago
      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)
      - pjhyett 16y ago
        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.
gcv 16y 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.
- gecko 16y 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.
  - zedshaw 16y 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.
    - gecko 16y ago
      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.
chappi42 16y 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 16y 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 16y 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 16y 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.
- FraaJad 16y 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 16y 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 16y 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 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 16y 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 16y ago
  Check out http://progit.org http://progit.org. It's awesome, and will teach you everything you need to know about git.
abstractbill 16y 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 16y 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 16y 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.
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.
experimentor 16y ago
A sampling of the Fossil code. This is the source browser code. http://www.fossil-scm.org/index.html/artifact?name=23a693054f1e70a9a63ca032ad5f66611cab0dfa 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 16y 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 16y 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 16y 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.

159 points by twampss 16y ago

jf 16y ago

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

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

FraaJad 16y 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 16y ago
  +1 mostly for an awesome handle
- jfager 16y 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.
  - FraaJad 16y ago
    agreed! I was running low on industrial terminology atm.
- wingo 16y ago
  > and the whole repository is just a single file http://keithp.com/blogs/Repository_Formats_Matter/ http://keithp.com/blogs/Repository_Formats_Matter/
stonemetal 16y 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.
- masklinn 16y 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.
- zedshaw 16y 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.

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

nex3 16y 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.
- pjhyett 16y 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.
  - masklinn 16y ago
    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)
    - pjhyett 16y ago
      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.

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

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

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

FraaJad 16y 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 16y 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 16y 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 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 16y 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 16y ago
Check out http://progit.org http://progit.org. It's awesome, and will teach you everything you need to know about git.

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

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.

experimentor 16y ago

A sampling of the Fossil code. This is the source browser code. http://www.fossil-scm.org/index.html/artifact?name=23a693054f1e70a9a63ca032ad5f66611cab0dfa 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 16y 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 16y 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 16y 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.