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.

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.

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.