151–160 of 175 posts
Earlier quoted context omitted.
Momentarily, yes. But it's just another central hub.
Nothing prevents you from using both, GitLab and GitHub.
Earlier quoted context omitted.
> It's mostly CI services and the like, all which break in some way when GitHub is down. It boggles my mind. If you're not adding a new dependency to the project, your CI server should never hit GitHub when doing builds. Who sets those things up without local cache?
Why shouldn't your CI get the source code it's building from GitHub?
Earlier quoted context omitted.
> Mainly, how do I share the issues and other problems that Github has did their own GUI for? I think this should not be done in the same system as where people store their source repos. Mixing the two is convenient, but can stifle innovation. Better to have flexible and well documented abstractions and good separation of concerns.
> Mixing the two is convenient, but can stifle innovation. Could you elaborate? I think I've heard the argument before, but I don't really see how. These outages show up again and again, partly because people cannot access the project issues.
Also keep in mind that protocols are much more important than the actual code implementing them (see git for a good example!)
Earlier quoted context omitted.
That sounds like a joke, but that's exactly the problem: the VCS has been distributed, but not all the services enmeshed around it: all the discussions (issues, pull requests, design debates, …). Github makes it easy to host git repositories, but so do a bunch of other services and it's not that hard to host your own either way or to set up trees of repository or multiple mirrors or what have you. The reason people u…
> The repository on its own has very little value. Depends for who. When I'm a user of a project, I don't care at all about anything other than the repository. The source code is the only thing that matters. Anyway, you can't really avoid centralization in most of the projects. Barring some extreme social experiments, a project always has identity, a "canonical version". That's your SPOF right there. Of course we hav…
The repository doesn't have any more value for that use case, tarballs would be just as good if not better.
I hope the world realizes that clouds are not just fluffy white things in the blue sky, but can create destructive storms too, with wind, rain and so on. Make sure your infrastructure is ready to weather such storms - have local backups and fallbacks, make sure your code is available even if github (or the Internet) goes down. The more I hear 'cloud', the more I try to depend only on tools that work offline.
It's the cloud-based offline tool storage platform that gives you access to your offline tools...from the cloud!!
Earlier quoted context omitted.
> Mixing the two is convenient, but can stifle innovation. Could you elaborate? I think I've heard the argument before, but I don't really see how. These outages show up again and again, partly because people cannot access the project issues.
Well, the argument holds for any big system. It is better to keep things modular and simple, so anybody can work on each of the components (in parallel), and improve each of the components, and replace them at will. Also keep in mind that protocols are much more important than the actual code implementing them (see git for a good example!)
If I sync a git repo from random location, I have the files to make that package. However none of the documents that aren't explicitly in the git repo are provided. With Git[hub/lab/...], this is metadata outside of the repo. Ideally, I want and need that as well. If there's an issue, I can research it quickly and see if it applies to me... Or if I'm a maintainer, I can make a solution offline and then merge it when online.
I understand that it may not be the perfect tool to include everything... but it does seem to fit the bill. Fossil does seem to do this correctly. I'll have to look into it.
Earlier quoted context omitted.
We do, it's called Fossil! http://fossil-scm.org/ Fossil tracks issues (tickets), documentation, and wiki pages at the same level as it tracks code, so when you clone a Fossil repo, everything gets downloaded to your local computer. You can then respond to tickets and perform repo maintenance offline, syncing everything to the server when you're back up. Edit: A few weeks ago I got a job a one-hour train ride away. I…
> http://fossil-scm.org/ Off-topic, but I'd reccomend that you install HTTPS Everywhere: https://www.eff.org/https-everywhere - the fact that you are linking the HTTP version means you don't have this very basic extension that really improves your security.
Earlier quoted context omitted.
That would make the downtime less correlated, but if it was higher in aggregate, would it be a net benefit?
I'm talking about a traditional sort of model, where each project hosts its own issue tracker, code review, etc. Unless you're working across multiple projects, you'd only care about downtime for your own server, not other people's (except perhaps for dependencies, which should be cached locally anyway).
Unless you're working across multiple projects, it doesn't matter to you that a GitHub outage takes out everyone else's projects at the same time.
Can you beat GitHub's uptime with a self-hosted solution? Sure. But you'll waste more time setting it up & managing it than you'd lose from GitHub downtimes.
Earlier quoted context omitted.
<3 Fossil. I wish it were more popular so I could use it on non-personal projects and still have a hope of attracting collaborators...
Yeah, fossil is all I use. It's so clean, tiny and self contained with no install or bloat. I've always been in love with software written that way. It makes me look at things like git as just a product of engineers that can get the job done, but don't know what it means to write good software or use imagination. Being fair, fossil performance on giant scale projects might not compare quite as well against git or pro…
You can't do patches. You can't rebase. You can't rename files.
Tell me all about this good software and imagination you speak of?
Earlier quoted context omitted.
That sounds like a joke, but that's exactly the problem: the VCS has been distributed, but not all the services enmeshed around it: all the discussions (issues, pull requests, design debates, …). Github makes it easy to host git repositories, but so do a bunch of other services and it's not that hard to host your own either way or to set up trees of repository or multiple mirrors or what have you. The reason people u…
Has anybody tried to store a project's metadata (issues and PRs) within the project's git repository itself? Seems like a logical step. If you don't want special git semantics around it, you'd have to be clever about how you store it so you don't have conflicts within the metadata. I.e. a naive design just adding a markdown file per issue or for all issues will require manual merging all the time. Still, it seems doa…