when to commit your source code to "the" repository

A friend of mine, Jeff, has been working for a defense contractor for a while. About a year ago, he was in town and we went to lunch, where he told me the awful news. People don't know how to use a version control system. (Or is it a revision control system?) The software developers there DO NOT commit there code to the repository until after they load it to production. He was bewildered by this. (I was too) They said... No, it's just too hard. Sometimes we move things around, thats a pain. Also, we are sure we have the same thing in the repository and production this way.

OK, I have some obvious problems with this that are hopefully obvious to you too. If not, you are not a geek and shouldn't be reading this post. What kind of repository is this? Apparently they are not keeping track of any of their development or bug fixes. So all they have in their repository are releases that hopefully match was was installed in production.

Fast Forward to yesterday....

Part-time, I subcontract to a Department of Energy contractor. They use PVCS. I stored a few scripts in a project directory in their PVCS. Great, I think to myself this is much less painful than all the paperwork. Minutes later, I notice and fix a few typos in the ReadMe.txt. I commit that change to PVCS. (If you've worked for a bureaucracy for many years, you may have just caught my mistake.)

So I have:

Script1      Version 1.0
Lib1         Version 1.0
ReadMe.txt   Version 1.1

A fellow system engineer is tasked with "loading it to plant." In normal speak this is "release to production." He's trying to push this through and get all the authorizations signed off. He gets a call, "Why is ReadMe.txt at version 1.1? What SCR (Software Change Request) was done to authorize those changes? You can't just go changing files willy-nilly."

Oh no! We've been TRAPPED! Really? Since the end of development ReadMe.txt been at Version 1.1 and all the testing was done on Version 1.1 - for some reason that should read Version 1.0. Why? Because at least one person doesn't know what a version control system is. Now if they were a "sophisticated" user, they would use TAGS and people that don't understand versions could just look at release tags. But they are not sophisticated users. How they document a release is inside their SCR (Software Change Request) document. You PASTE the versions of all the files you are releasing into this document. This is your poor man's tag. Well, apparently it's a poor man's tag only when convenient for the people in control. At the stage we got the (you've been caught) call, it was not a poor man's tag. The version on the file is some how the release version.

How did we make them happy? We removed the ReadMe.txt from the SCR document as it was not a file we were installing anyway.

A couple questions:

• Has anyone ever seen this sort of use/abuse of a version control system? Was it at a government contractor?
• What would have happened if all the files were 1.1? Would it pass detection?
• Should I ask if there is another repository that I can use for source code version control?
  

Doesn't look like I'm the only person that believes in "commit early, commit often."