Live data from Hacker News

Why I Use Fossil

sheddingbikes.com

31–40 of 54 posts

Re: Why I Use Fossil

#31
post #12

Earlier quoted context omitted.

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.

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)

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.

Re: Why I Use Fossil

#32
post #31

Earlier quoted context omitted.

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)

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.

People said that same sort of thing about RoR or Django too. "What?! You have to do it the way they want? I prefer fooORM!", and so on. The point is not that it is great at whatever, the point is it get stuff out of the way at start time, and allow you to get to the meat of it quickly. Later on if the project turns into something interesting, you can switch to redmine, or put a real wiki behind it, and so on (but only as really needed).

Re: Why I Use Fossil

#33
post #31

Earlier quoted context omitted.

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.

People said that same sort of thing about RoR or Django too. "What?! You have to do it the way they want? I prefer fooORM!", and so on. The point is not that it is great at whatever, the point is it get stuff out of the way at start time, and allow you to get to the meat of it quickly. Later on if the project turns into something interesting, you can switch to redmine, or put a real wiki behind it, and so on (but onl…

That's an interesting point in light of Rails' recent movement towards more modularity. It suggests that there may be room for a Fossil-like abstraction over Git that has (pluggable?) built-in cloned-by-default issues, wiki, etc.

Re: Why I Use Fossil

#34
post #33

Earlier quoted context omitted.

People said that same sort of thing about RoR or Django too. "What?! You have to do it the way they want? I prefer fooORM!", and so on. The point is not that it is great at whatever, the point is it get stuff out of the way at start time, and allow you to get to the meat of it quickly. Later on if the project turns into something interesting, you can switch to redmine, or put a real wiki behind it, and so on (but onl…

That's an interesting point in light of Rails' recent movement towards more modularity. It suggests that there may be room for a Fossil-like abstraction over Git that has (pluggable?) built-in cloned-by-default issues, wiki, etc.

Honestly I've always wondered why redmine, trac, et al don't already build their wiki on top of the vcs anyway, instead of using a separate database with tracking. Such a step seems counter-productive.

Re: Why I Use Fossil

#35
post #8

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.

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.

Re: Why I Use Fossil

#36

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.

'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, fundame…

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.

Re: Why I Use Fossil

#37
post #33

Earlier quoted context omitted.

That's an interesting point in light of Rails' recent movement towards more modularity. It suggests that there may be room for a Fossil-like abstraction over Git that has (pluggable?) built-in cloned-by-default issues, wiki, etc.

Honestly I've always wondered why redmine, trac, et al don't already build their wiki on top of the vcs anyway, instead of using a separate database with tracking. Such a step seems counter-productive.

I can see arguments both ways. Having the wiki separate means that the repo doesn't get polluted with unrelated commits (especially important for SVN which doesn't have branches), and it makes setup at least somewhat easier, since an extra push-capable user doesn't need to be added.

Re: Why I Use Fossil

#39
post #37

Earlier quoted context omitted.

Honestly I've always wondered why redmine, trac, et al don't already build their wiki on top of the vcs anyway, instead of using a separate database with tracking. Such a step seems counter-productive.

I can see arguments both ways. Having the wiki separate means that the repo doesn't get polluted with unrelated commits (especially important for SVN which doesn't have branches), and it makes setup at least somewhat easier, since an extra push-capable user doesn't need to be added.

>> (especially important for SVN which doesn't have branches)

explain.

Re: Why I Use Fossil

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

Post reply on HN