5 ms·
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 sour
by 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 agoI 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 agoWe'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 agoExportable 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 agoIntegrating 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.
- sophacles 16y agoPeople 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).
- nex3 16y agoThat'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.
- sophacles 16y agoHonestly 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.
- nex3 16y agoI 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.
- 16y ago
- nex3 16y agoThis is exciting news. masklinn is right that it probably won't entirely address Zed's points, but for people like me who don't care as much that it's baked in, this is very cool.
- Tichy 16y agoI think that the concern with #1 was not having one's stuff one somebody else's server. It is that if said server becomes unavailable, there is no alternative left. So if you bet on git, how do you get your nice wikis, bug trackers, HTTP access and whatnot without GitHub?