Compliance in DVCS administration at an enterprise context, what to expect from a transition from a CVCS (Perforce)?

dukeofgaming asked:

I work in a big multinational company as a software engineer and I’m currently holding a very nice conversation with IT and other developers with regards to adopting a DVCS (Mercurial and/or Git).

One of the issues raised by IT was compliance and intellectual property (BTW, Perforce talks loudly about this and in relation to Git). It seems to me that IT is under the impression that because Mercurial/Git are distributed, having repositories in every developer machine is an out-of-control scenario and they would have to audit every single repository.

Another thing that I think is a concern to IT is the fact of now having “100” repositories instead of “10” humongous ones, I’m under the impression that they think their administrative effort to maintain/monitor them would grow “ten-fold”. I think repository management software (Rhodecode, Atlassian Stash) would be the first step towards giving access control & traceability.

My questions are:

  1. Is repository management software enough for a company this size (lets say ~2000 developers & ~50 Perforce depots over ~10 servers)?, to be compliant (and meet other enterprise requirements?)

  2. What exactly is encompassed by this “compliance” requirement?, are there any references you can give (e.g. an IEEE standard or something like that)?

My company has used Perforce for ~10 years

My answer:


Not much really changes when you switch to a DVCS. The big difference is that the copy of the source code on every developer’s workstation is now its own repository as well.

I doubt there’s much reason for IT to worry about this. Just because git and mercurial are distributed, doesn’t mean you will be deploying/delivering directly from some developer’s desktop. It’s still possible – and almost certainly necessary – to continue using some central repos that everyone checks into, for testing, QA and eventual release.

Whether IT is monitoring source code on developer workstations or not, nothing really changes. You’re still going to get the change history into the central repos as soon as they’re pushed, which is what I suspect they’re really concerned about.

What you gain from this from an IT standpoint is that you aren’t hitting the central repos every few minutes (or seconds!) whenever the developers make a commit. Developers can finish working on something and then push it up only when it’s ready, but still have complete version control on their workstation without having to hit the network nearly so much.

Finally, you need to have a more detailed chat with IT regarding the exact nature of the compliance issues they’re talking about. This could be anything from managing intellectual property, ISO 9000, or some government laws/regulations.

(To all: feel free to improve this answer; this is not my area of expertise…)


View the full question and answer on Server Fault.

Creative Commons License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.