5 ms·

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

by teej 12y ago

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.
  - gnaffle 12y ago
    Well, you do that anyway when you allow people to check out a local copy of the code. Just as in most VCSes, you can set up a git server to only allow checkout of specific branches.
    - Xylakant 12y ago
      >Well, you do that anyway when you allow people to check out a local copy of the code. You grant that permission to the person legitimately checking out code, but not to the person finding or stealing a laptop with a clone of a repository. The latter is a side-effect of how a DVCS works. In SVN you don't even need to expose the full history, you can grant access to the last revision only. > Just as in most VCSes, you can set up a git server to only allow checkout of specific branches In SVN for example you can restrict people to single directories (or even files - I don't remember exactly). That at least is impossible in git. I can prevent pushes using hooks but not reads.
      - gnaffle 12y ago
        > You grant that permission to the person legitimately checking out code, but not to the person finding or stealing a laptop with a clone of a repository. The latter is a side-effect of how a DVCS works. I'm not sure what you're getting at. What difference is there (not that you would allow checkouts on unencrypted laptops anyway)? > In SVN you don't even need to expose the full history, you can grant access to the last revision only. > In SVN for example you can restrict people to single directories (or even files - I don't remember exactly). That at least is impossible in git. I can prevent pushes using hooks but not reads. These restrictions may be useful in some cases, but I would wager that they are far more seldom than some of the advantages of git (like being able to work offline).
        Xylakant 12y ago
        > I'm not sure what you're getting at. What difference is there A checkout from SVN/CVS only contains the last version. Files that were deleted in an earlier version are only on the server. A clone of a DVCS contains all versions and all files that ever were in the repo (unless you use BFG or git-filter-branch, but people tend to forget that). So a clone can contain secrets that people are not aware of, such as accidentally committed and deleted files. An interested party could find stuff that you're not aware off by looking at HEAD. > (not that you would allow checkouts on unencrypted laptops anyway)? That's not my call to make, but I agree on that regard. Reality sadly different from what we both wish.
- 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.

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

by teej 12y ago

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

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.
- gnaffle 12y ago
  Well, you do that anyway when you allow people to check out a local copy of the code. Just as in most VCSes, you can set up a git server to only allow checkout of specific branches.
  - Xylakant 12y ago
    >Well, you do that anyway when you allow people to check out a local copy of the code. You grant that permission to the person legitimately checking out code, but not to the person finding or stealing a laptop with a clone of a repository. The latter is a side-effect of how a DVCS works. In SVN you don't even need to expose the full history, you can grant access to the last revision only. > Just as in most VCSes, you can set up a git server to only allow checkout of specific branches In SVN for example you can restrict people to single directories (or even files - I don't remember exactly). That at least is impossible in git. I can prevent pushes using hooks but not reads.
    - gnaffle 12y ago
      > You grant that permission to the person legitimately checking out code, but not to the person finding or stealing a laptop with a clone of a repository. The latter is a side-effect of how a DVCS works. I'm not sure what you're getting at. What difference is there (not that you would allow checkouts on unencrypted laptops anyway)? > In SVN you don't even need to expose the full history, you can grant access to the last revision only. > In SVN for example you can restrict people to single directories (or even files - I don't remember exactly). That at least is impossible in git. I can prevent pushes using hooks but not reads. These restrictions may be useful in some cases, but I would wager that they are far more seldom than some of the advantages of git (like being able to work offline).
      - Xylakant 12y ago
        > I'm not sure what you're getting at. What difference is there A checkout from SVN/CVS only contains the last version. Files that were deleted in an earlier version are only on the server. A clone of a DVCS contains all versions and all files that ever were in the repo (unless you use BFG or git-filter-branch, but people tend to forget that). So a clone can contain secrets that people are not aware of, such as accidentally committed and deleted files. An interested party could find stuff that you're not aware off by looking at HEAD. > (not that you would allow checkouts on unencrypted laptops anyway)? That's not my call to make, but I agree on that regard. Reality sadly different from what we both wish.
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.