5 ms·

You know you can run git internally as well? Using github as an excuse to stay with svn seems rather ill informed. You wouldn't lose hours if github is down.

• deleted 14y ago
  [deleted]
• hp50g 14y ago
  We'd lose our deployment, integration tests, continuous integration, ability to pull other team changes from the master and code review platform. That's a big chunk of our dev infrastructure. Size is mentioned as to be honest we moved a load of stuff to git in 2011 as a test case and it couldn't handle it. We have some test fixture data files (big ones) that it choked on. Not only that, you can't compose software easily without introducing external tooling.
  • arianvanp 14y ago
    git is decentralized. Any sane sysadmin wouldn't use github as a 'central' point, but set up an own remote to which you push. Then every once in a while from that remote, commits are pushed to github. heck you wouldn't even really need a remote.
    • elithrar 14y ago
      Alternatively you can set up an alias (i.e. "all") for multiple remotes and just push to them in one hit. Useful when I'm pushing code to Heroku and GitHub simultaneously.
      • hp50g 14y ago
        Aliases on that scale are like hosts files. An utter shit to manage. Its why they invented dns which is a centralized delegated service. The "single source of truth" is hard to avoid.
  • teej 14y ago
    So your desire to not use Github has nothing to do with Github then.
  • Volpe 14y ago
    > We'd lose our deployment, integration tests, continuous integration, ability to pull other team changes from the master and code review platform. That's a big chunk of our deb infrastructure. You'd lose all that from using git? Why? Are you saying if you switched to git without switching any of your svn infastructure? We aren't talking about github downtime anymore are we... > Size is mentioned as to be honest we moved a load of stuff to git in 2011as a test case and it couldn't handle it. A repo I interact with daily is now pushing 54gb, it contains large test fixtures that have HD videos, and images in it. I've never had any issues. (It takes a while to copy it around...)
  • andreyf 14y ago
    Your deployment really shouldn't rely on your VCS... Just added a 3 GB file to my github repo. It took <2m, most of which I imagine was spent gzip-ing it.
    • hp50g 14y ago
      Well it doesn't. We package every rev that's made as part of our integration process. Then we choose one and deploy it (using our auto deployment software which farts out packages across 100-odd machines, per instance..).
• huherto 14y ago
  To me github is the killer feature of git. I think svn is easier and more appropiate for a corporate environment.
  • jlgreco 14y ago
    Really? Git seems like the killer feature of Github to me... Why do you think that git is inappropriate for a corporate environment? I've been using it in one for a few years now and see nothing wrong with that.
  • delano 14y ago
    svn is fine for very small, highly co-ordinated teams which is rare in a corporate environment. It's decidedly not fine for complex merging, development outside of the private network, or maintaining multiple versions of the same codebase (customer installs) among other things.
    • Peaker 14y ago
      Even then, doing without "add -p", "rebase -i", "commit --amend", inplace branches, and various other git features is going to cost you.
  • FuzzyDunlop 14y ago
    I think the killer feature of git -- which applies to any other DVCS -- is that you're not dependent on github if you're well prepared. There's absolutely nothing stopping you adding redundant remotes so you always have somewhere to push/pull changes and deploy from. git remote add <remote_name> url
    • hp50g 14y ago
      Yep and that's like managing dns with host files...
  • rubyrescue 14y ago
    the achilles heel of svn is branches cost 100% of the branched repository. even an svn repo with one user can be prohibitively large. even in a corporate lan environment just pulling down an svn repository can take far too long