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.
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.
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.
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.
So, the performance of binary assets in SVN is exactly why we used to--when doing game development--check all the source files out into their own repository, and occasionally sync over.
As for the configuration being in the same repo as the code--again, why? That tells me that you aren't packaging releases, or if you are, your documentation is less useful as a reference than your code.
These are antipatterns, again, and "fixing" your VCS isn't going to help in the long run.
> So, the performance of binary assets in SVN is exactly why we used to--when doing game development--check all the source files out into their own repository, and occasionally sync over.
The assets for game development likely are bigger than the assets in web development but we never had major issues with binaries. Things also improved much in later SVN versions (in the beginning the client was way to stupid and tried to diff binaries which obviously could not work)
> As for the configuration being in the same repo as the code--again, why?
Why not? I don't have that right now, but I'd like to have it. Because I could compare the state of the code and the state of the configuration with the state of the code easily at any time at any commit. I could use bisect to figure out at which point things started failing. Helps when you're trying to figure out when config and code started drifting apart. I can use google's repo tool or submodules or stitch together the config repo and the code repo by matching up dates or tagged versions, but that's all a hack. It's maybe the best hack currently available, but I still think there's room for improvement.
> That tells me that you aren't packaging releases, or if you are, your documentation is less useful as a reference than your code.
I can't imagine how you reach that conclusion. You could not be further from reality. Just because I'd consider it nice if I could have a single version identifier in a single repo that matches up both, config and code I'm not rolling that in a package? And how does that relate to my documentation?
> 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?
Of course they do. But those repos should live on an internal repo server, and on the production systems themselves.
Copying production authentication credentials to a non-production machine should be a firing offence.
> 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?
Hell no. Code without configuration is like a gun without bullets: it's an interesting piece of work, but that's it (I'm not a huge believer in intellectual property, you can tell). But configuration is the keys to the kingdom. If a cracker has your app's code, he might be able to figure out some flaws in your protocols or your implementation, but if a cracker has your database passwords, your hostnames and IP addresses, your firewall configuration, your bastion hosts—then you're dead.
Enlighten me, I'm seriously interested in knowing, because I'm missing the point:
Currently there's code in one repo and configuration in another. Both repos are on the same internal repo server. Both repos are accessible to multiple persons - some can access the code only (developers) and some can access the configuration repo only and some can access both repos (admin). A build process tags both repositories and builds an artifact that gets deployed.
How is that situation superior in terms of security over:
Code and configuration live side by side in the same repository that supports access controls. The repository is hosted on an internal repo server. The parts that are code are accessible to developers only and admins can access both parts. A build process tags the repository and builds an artifact that gets deployed.
The only point I could see is that with two repositories it's harder to mess up the authentication, but I doubt that's true. In both scenarios we have people with access to the configuration and those people will in a lot of organization have a copy on their laptop that they carry around. That's how most people use version control. In both setups it would be possible to only ever handle the sensitive data on a remote system, but that's a property of the workflow and not a property of the VCS used. I seriously don't see the issue with a shared repo - if it supports access controls.
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.