A couple of other reasons to use centralized version control: 1: You are a Fortune 100 company and need to have access control on your codebase (so you can give contractors access to only a few files for example) 2: The code you are writing is subject to regulatory control.

Interesting you should mention that. We have our code on a corporate SVN server but I used git (via git svn) to create a mirror for some offshore developers outside the export control bubble. Git allowed me to exclude a set of files very easily. Not an argument pro or con either system, just saying.

This is why we use svn still.

Also, its easier for developers not to fuck it up royally.

sorry, help me understand here. How does something who's only method of control is tied to the ide you use keeping any control over the source code?

you can still use git-tfs to use tfs like you would use svn. you can also just copy the file to another folder and suddenly everything is good. or you use time machine or another other backup mechanism.

Do i miss something magic that tfs does, that I don't understand?

I can't speak for TFS, so maybe they do something daft, but it's usual that when you get latest from the server you simply won't get the files you aren't allowed to. You won't even see them. It's access control at a finer grain than the repository level, applied on the server side.

(with git always giving you the whole repository, there's not much you could do with git, but but many systems don't do that.)

I've never used TFS but my understanding is that TFS server allows you to configure it to only give a specific person access to a specific set of files.

For example: One could tell the TFS server "Deny Contractor-X access to all files, except for files A, B, and C". I assume that this would only allow Contractor-X to access files A, B, and C. Even if they were using git-tfs.

> 2: The code your are writing is subject to regulatory control.

Can you expand on what, precisely, you mean by that?

If I remember correctly, certain regulatory environments require that an audit log be kept of who saw which file and when.

> If I remember correctly, certain regulatory environments require that an audit log be kept of who saw which file and when.

Okay, let's say that's your environment. How do you prevent Mole Manny (who is a legit developer in your organization) from pulling down all the files in his project (as he's entitled to do), and then copying it over to his $super_sneeky_storage_system?

We've talked a lot about this where I am and we've concluded that to ensure a super-tight environment we'd have to do a slew of really heinous lockdowns (epoxy usb ports for instance) which would likely not really do much against moles but slow down and anger legit users.

Really? The only places I've run into regulatory requirements for audit logs of seeing data is when the data itself is sensitive government data or is legally protected personal data; outside of national security, those aren't the kind of things that generally apply to code (and in the national security space, I'd imagine that you'd need more comprehensive monitoring of your systems, desktop or server, such that using centralized VCS for the purpose would be redundant [alone, centralized VCS for that purpose has holes big enough to drive a truck through, since it can't monitor who sees information once it is checked out, only who checked it out].)

If you write medical device or flight-control software, you have to have traceability all the way from requirements to the delivered binaries. With a central server & build system, that's much easier to do & also explain to federal inspectors.

I've worked on things like poker machine software.

Pieces like the random number algorithm for that stuff is tightly controlled.

I can speak from my own experience there are times where depending on funding, portions of a project must be developed by U.S. citizens... but the bigger project can have parts developed over seas. Depending on funding and the project.

Some code like encryption algorithms cannot leave the United States by law (if developed by a US company/Citizen).

Another example might be Credit Card Processing software, you don't want a lot of people knowing how you generate your encryption keys.

If your encryption key generation security depends on people not knowing how you generate keys, then it's totally busted.

Ah, but the question isn't Is this a good idea? but Is this legally required?

Not always the same.

It may not depend on it, but it will improve it by some small margin most of the time.

Centralized version control doesn't have any advantage over distributed version control for either of those scenarios. Particularly, it doesn't give you any more control over where the code goes after someone with authorized read access to the repository makes their own copy of it.

For that, you need comprehensive monitoring on every system from which the repository can be accessed that tracks what is done, and once you have that, it doesn't really matter what you do for VCS for that kind of monitoring.