Almost all teams these days that I know of have a revision / source / version control system of some kind purchased and installed. The "purchased" ones are usu

Almost all teams these days that I know of have a revision / source / version control system of some kind purchased and installed. The "purchased" ones are usually worse than the open source ones (e.g. - Git, SVN et al). The "ENTERPRISE!!!" devs don't use the system effectively, usually: haul things off to a corner for weeks before doing a single check-in/commit; may or may not know how to branch; bumble with breakage during merge/pull operations; end-run the system by releasing non-compiled files directly to production without saving them in source control. Source control use is like the other comment about programming language: the main issue is not whether you have used brand X, but whether or not you have a coherent mental model of what the hell you are doing in the first place. That said, there are some BAD commercial source control systems out there, preying upon the "you need this, even/especially if you don't really know why" crowd. These are usually sold to The Management in terms of the control they bring to source control - they will have a trigger to force entry of a trouble/enhancement ticket to go with a check-in/commit. That fact that they suck at source management is of no consequence (e.g. - painfully slow, little to no command line interface for automation, poor research/discovery features, poor branch/merge support, unreliable / data corruption)