It's a valid tradeoff to make, but still something I'd keep in mind.
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.
If your developers are deploying into production directly from their laptops, you have a problem.
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.
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.
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?
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.
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.
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.
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).
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.
Well, that goes without saying. But I don't think that security argument is a very poor one compared to the huge benefit of having the history locally to inspect.
We've had instances where secrets were committed to local repositories by accident. It never got past review and into the master branch. If it had, we would probably had taken the effort to rewrite that commit out of the history.
If you go further upthread you'll find that I said "a valid tradeoff, but one I'd keep in mind"
> We've had instances where secrets were committed to local repositories by accident.
That's laudable, but countless examples show that not everyone is that diligent. I'd love if I could lock down some parts of some repos so that they're only accessible by people that I have an elevated level of trust in. (and where I can enforce a certain security level on the laptop).
Sure, then again I would guess that the ones who are not that diligent are not likely to apply those access restrictions that you mention (although the "one revision" advantage is something they would get "for free" with SVN).