6 ms·

> That's now known as "I can't deploy because github is down". Note that the author proposes "local commits plus a centralized storage". And in that cause you

> That's now known as "I can't deploy because github is down". Note that the author proposes "local commits plus a centralized storage". And in that cause you can scp your repo somewhere and change your origin and move on. Also, do people really rely on 3rd party services for their deployed code? I've used github as a repo and colab tool at companies, but we still deployed from repos owned by the company. > I'd even go out and argue that most use-cases are solved just as good by a solid centralized system with less complexity involved. I'd go out an argue that because the added complexity of git is far outweighed by the benefits of a local repo.

teej 12y ago
Also, do people really rely on 3rd party services for their deployed code? Yes, this is very common.
- gfodor 12y ago
  Also the fact that each developer has a full copy of the repo on their laptop lets me sleep at night wrt github exploding.
  - TeMPOraL 12y ago
    Or your company exploding or pretty much anything exploding. When every dev has a full copy of the repo, you can restore all the work as long as a single dev machine is alive. Not to mention that in case of an office Internet outage, you can just mesh together those repos and continue working. Knowing that gives me some peace of mind.
  - Xylakant 12y ago
    It also means that you get to loose control over all data in the repo including all versions and history when a single person looses the laptop, even if it's a person that only required read access to a tiny part of the data. It's a valid tradeoff to make, but still something I'd keep in mind.
    - angersock 12y ago
      I'm going to go ahead and say that that's a red herring. A successful business is built upon so much more than whatever code is in your repo. Any competitors are probably more likely to look at the code and ignore it over their own home-grown solution than to adopt it wholesale...and if they can beat you with your own code, they would've beaten you without it, because they probably run a much better business game. Trade secrets are like the stupidest reason ever to hobble your developers.
      - Xylakant 12y ago
        I think you're wrong on that account, there's tons of pain that can be caused by such a loss. But I was thinking more about the SSL certificates and SSH keys and hardcoded passwords and other secrets that inevitably seem to end up in repositories. (Rails cookie secrets anyone?) Some of that data gets deleted but not purged correctly and oops, there's that one server that still accepts last years key, didn't we delete that from the repo? I've seen some repos that could easily create damage in the 6-7 figure range if they ended up in the wrong hands. Enough to sink a small company in any case.
        wtbob 12y ago
        All of that is configuration, not code, any should never be in any repo external to one's company. Nor, frankly, should it be available to the developers. That's all production-specific, and should be restricted to deployment. If your developers are deploying into production directly from their laptops, you have a problem.
        Xylakant 12y ago
        So, admins never use version control for puppet manifests/chef cookbooks/terraform/saltstack/whatnot and all the config data that's put on the servers? And it would not be of value if we could version the configuration along in the same repository as the code to which it belongs? So it's easier to track? Now, currently we can't, because DVCS don't allow us to grant different privileges to different people/groups, but I could very well imagine that developers get access to a repo where they can change the configuration to the dev/test environments and the admins match that in the same repo for prod and other envs with higher level needs. I could also imagine building the final deployment from a single repo instead of having to merge two repos because I need to separate them due to permissions. I could also imagine designers placing their assets in the repository without needing to deal with git or even seeing the source code that lives side-by-side. That totally used to work with SVN I'd totally like it if the repository contained the PSD sources for all the assets/mockups that are relevant for a given version of the source, but alas, you can't check out the source without getting the PSDs, even if you're not interested in them. Heck, SVN even allowed exposing the repo as webdav which you could mount as a networked folder, so people could access the last revision just as if it were a SMB drive. git is a huge step forward in some regards, but we also lost quite a couple of good things along the way. > If your developers are deploying into production directly from their laptops, you have a problem. I never said they do.
  - silverbax88 12y ago
    Or, you could use Mercurial and sleep even better knowing that not only does every dev have a full copy, but does NOT have thousands of orphaned files of each revision or potential revision like Git does.
  - pyre 12y ago
    Cloning doesn't require the full repo. Some of your devs may only have half of the repo. Look at the --depth option for git-clone.
mordocai 12y ago
Hell, for a ton of companies (including mine) everything is on 3rd party services/servers. We don't have any servers we can actually call our own.
- kbenson 12y ago
  Which is fine, but the very obvious and up-front trade-off of using servers that aren't yours is that they aren't yours, and everything that implies. There are plenty of benefits as well, but that's why it's a trade-off.
Xylakant 12y ago
> And in that cause you can scp your repo somewhere and change your origin and move on. If you happen to have - god forbid - a php app that pulls dependencies via composer you have a hard dependency on github since composer pulls practically all code from GH. I don't consider that a good idea, but that's how it currently is. [No, I don't do php and only sometimes have to clean up the resulting fallout]
- structural 12y ago
  If particular frameworks want to tie themselves to a single server/host, that's their problem, and is specifically not a problem with any of Github, git or DVCSes generally. You really cannot stop all people from being idiots all of the time.
- ksenzee 12y ago
  That's not a hard dependency, it's a sensible default that you should be overriding if you're running composer install as part of your deployment process instead of including composer's vendor directory in your repo. Documentation: https://getcomposer.org/doc/05-repositories.md https://getcomposer.org/doc/05-repositories.md
  - Xylakant 12y ago
    Practically all packages use git sources. Yes, you can vendor them - congratulations, you just kicked the can down the road and moved the issue to the build step. The issue exists for other languages as well - maven/mavencentral, ruby/rubygems.org - but only composer depends on github very much. I don't like that but it's not like the other solutions are much better.
    - mercurial 12y ago
      Many companies mirror maven, so having mavencentral go down is not a big issue. Does composer make it possible to deploy a mirror of its dependencies?
      - 12y ago
stcredzero 12y ago
I'd go out an argue that because the added complexity of git is far outweighed by the benefits of a local repo. But for precisely what use cases or in what situations? If one is a novice and just want to have source control and versioning, centralized systems are going to have the better cost/benefit.
- sanderjd 12y ago
  > If one is a novice and just want to have source control and versioning, centralized systems are going to have the better cost/benefit. This seems completely backwards to me. When I was in college, I thought it was a giant pain to source control my homework, because the options I was aware of (since all I knew about was SVN) were 1) public hosting on sourceforge (which was itself a pain to use), which professors were not keen on, 2) find a private host somewhere (not sure I ever did), 3) run my own server somewhere, 4) configure and run a local server. I went with (3) and (4) but it was never an easy or novice-friendly solution, and mostly I just didn't version control things. The local version control model of DVCS would have been much easier. It's only when working with other people that any extra complexity even rears its head at all, which doesn't come up if you're a novice who just wants to have source control and versioning.
  - Xylakant 12y ago
    a purely local svn repository never needed a server. svnadmin </path/to/repo/on/local/disk> followed by svn checkout <file:///path/to/repo/on/local/disk> is all it ever needed.
    - joeyo 12y ago
      Same for git, though.

teej 12y ago

Also, do people really rely on 3rd party services for their deployed code? Yes, this is very common.

gfodor 12y ago
Also the fact that each developer has a full copy of the repo on their laptop lets me sleep at night wrt github exploding.
- TeMPOraL 12y ago
  Or your company exploding or pretty much anything exploding. When every dev has a full copy of the repo, you can restore all the work as long as a single dev machine is alive. Not to mention that in case of an office Internet outage, you can just mesh together those repos and continue working. Knowing that gives me some peace of mind.
- Xylakant 12y ago
  It also means that you get to loose control over all data in the repo including all versions and history when a single person looses the laptop, even if it's a person that only required read access to a tiny part of the data. It's a valid tradeoff to make, but still something I'd keep in mind.
  - angersock 12y ago
    I'm going to go ahead and say that that's a red herring. A successful business is built upon so much more than whatever code is in your repo. Any competitors are probably more likely to look at the code and ignore it over their own home-grown solution than to adopt it wholesale...and if they can beat you with your own code, they would've beaten you without it, because they probably run a much better business game. Trade secrets are like the stupidest reason ever to hobble your developers.
    - Xylakant 12y ago
      I think you're wrong on that account, there's tons of pain that can be caused by such a loss. But I was thinking more about the SSL certificates and SSH keys and hardcoded passwords and other secrets that inevitably seem to end up in repositories. (Rails cookie secrets anyone?) Some of that data gets deleted but not purged correctly and oops, there's that one server that still accepts last years key, didn't we delete that from the repo? I've seen some repos that could easily create damage in the 6-7 figure range if they ended up in the wrong hands. Enough to sink a small company in any case.
      - wtbob 12y ago
        All of that is configuration, not code, any should never be in any repo external to one's company. Nor, frankly, should it be available to the developers. That's all production-specific, and should be restricted to deployment. If your developers are deploying into production directly from their laptops, you have a problem.
        Xylakant 12y ago
        So, admins never use version control for puppet manifests/chef cookbooks/terraform/saltstack/whatnot and all the config data that's put on the servers? And it would not be of value if we could version the configuration along in the same repository as the code to which it belongs? So it's easier to track? Now, currently we can't, because DVCS don't allow us to grant different privileges to different people/groups, but I could very well imagine that developers get access to a repo where they can change the configuration to the dev/test environments and the admins match that in the same repo for prod and other envs with higher level needs. I could also imagine building the final deployment from a single repo instead of having to merge two repos because I need to separate them due to permissions. I could also imagine designers placing their assets in the repository without needing to deal with git or even seeing the source code that lives side-by-side. That totally used to work with SVN I'd totally like it if the repository contained the PSD sources for all the assets/mockups that are relevant for a given version of the source, but alas, you can't check out the source without getting the PSDs, even if you're not interested in them. Heck, SVN even allowed exposing the repo as webdav which you could mount as a networked folder, so people could access the last revision just as if it were a SMB drive. git is a huge step forward in some regards, but we also lost quite a couple of good things along the way. > If your developers are deploying into production directly from their laptops, you have a problem. I never said they do.
- silverbax88 12y ago
  Or, you could use Mercurial and sleep even better knowing that not only does every dev have a full copy, but does NOT have thousands of orphaned files of each revision or potential revision like Git does.
- pyre 12y ago
  Cloning doesn't require the full repo. Some of your devs may only have half of the repo. Look at the --depth option for git-clone.

mordocai 12y ago

Hell, for a ton of companies (including mine) everything is on 3rd party services/servers. We don't have any servers we can actually call our own.

kbenson 12y ago
Which is fine, but the very obvious and up-front trade-off of using servers that aren't yours is that they aren't yours, and everything that implies. There are plenty of benefits as well, but that's why it's a trade-off.

Xylakant 12y ago

> And in that cause you can scp your repo somewhere and change your origin and move on. If you happen to have - god forbid - a php app that pulls dependencies via composer you have a hard dependency on github since composer pulls practically all code from GH. I don't consider that a good idea, but that's how it currently is. [No, I don't do php and only sometimes have to clean up the resulting fallout]

structural 12y ago
If particular frameworks want to tie themselves to a single server/host, that's their problem, and is specifically not a problem with any of Github, git or DVCSes generally. You really cannot stop all people from being idiots all of the time.
ksenzee 12y ago
That's not a hard dependency, it's a sensible default that you should be overriding if you're running composer install as part of your deployment process instead of including composer's vendor directory in your repo. Documentation: https://getcomposer.org/doc/05-repositories.md https://getcomposer.org/doc/05-repositories.md
- Xylakant 12y ago
  Practically all packages use git sources. Yes, you can vendor them - congratulations, you just kicked the can down the road and moved the issue to the build step. The issue exists for other languages as well - maven/mavencentral, ruby/rubygems.org - but only composer depends on github very much. I don't like that but it's not like the other solutions are much better.
  - mercurial 12y ago
    Many companies mirror maven, so having mavencentral go down is not a big issue. Does composer make it possible to deploy a mirror of its dependencies?
    - 12y ago

stcredzero 12y ago

I'd go out an argue that because the added complexity of git is far outweighed by the benefits of a local repo. But for precisely what use cases or in what situations? If one is a novice and just want to have source control and versioning, centralized systems are going to have the better cost/benefit.

sanderjd 12y ago
> If one is a novice and just want to have source control and versioning, centralized systems are going to have the better cost/benefit. This seems completely backwards to me. When I was in college, I thought it was a giant pain to source control my homework, because the options I was aware of (since all I knew about was SVN) were 1) public hosting on sourceforge (which was itself a pain to use), which professors were not keen on, 2) find a private host somewhere (not sure I ever did), 3) run my own server somewhere, 4) configure and run a local server. I went with (3) and (4) but it was never an easy or novice-friendly solution, and mostly I just didn't version control things. The local version control model of DVCS would have been much easier. It's only when working with other people that any extra complexity even rears its head at all, which doesn't come up if you're a novice who just wants to have source control and versioning.
- Xylakant 12y ago
  a purely local svn repository never needed a server. svnadmin </path/to/repo/on/local/disk> followed by svn checkout <file:///path/to/repo/on/local/disk> is all it ever needed.
  - joeyo 12y ago
    Same for git, though.