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."

Tucows/Comodo code signing certificate for Java

I might as well document this process out here for others.

Comodo through Tucows is the known cheapest way to sign Java code. So that's what we went for. In addition to parting with $75, plan on a day of finding verification documents and keeping the ball in their court.

The process is supposed to go like this:

1. Signup with Tucows to be an author. (free)
   
2. Use their "author resources" to order a Comodo certificate.
3. Verify you are who you say you are with Comodo.
4. Download certificate and start signing your Java jars.
   

The problem is, the flow between Tucows and Comodo is very loose. It takes 2-3 days to get handed off to Comodo after you start your order with Tucows. Then it takes a day for Comodo to start asking you questions. After that, from our experience, count on bouncing information to Comodo atleast 6 times over the course of 3 days. In our case, our $75 code signing probably cost us $500 if you include our time. On the other hand, it's probably a hastle with everyone.

Problem #1:
It seems for their Corporate verification, it's fairly indepth. I think we were able to be verified with: Articles of Incorporation, Acceptance of S-Corp, company bank statement, and phone bill.

Problem #2:
We were just about to move HQ to a new corporate address. I gave them our new corporate address, none of our documents support that address. So I had to tell them to change my order's address to our existing/current corporate address.

Problem #3:
We don't have a land line in our business name. We have a Google Voice number that forwards to our cell phones. This sounds all smart and modern, but caused us problems in this case. We had to jump through additional hoops to get them to accept our cell phone bill.

Once you get all the OKs, they finally send you a link to "collect your code signing certificate." BTW, you are supposed to use the same computer and browser from start to finish. It's doing some certifying magic. So you go to the collection link, and your browser (or javascript) has a popup that a certificate is installed. Now you just stare at the page that doesn't have any forward navigation.

So, you'll probably do what I did and search for how to USE your Comodo certificate. Google tells me some good things that aren't obvious from the Comodo page.

• https://support.comodo.com/index.php?_m=knowledgebase&_a=viewarticle&kbarticleid=419
• https://support.comodo.com/uploaded/UsingComodoAuthenticodeCertificateforJava.pdf
  

Those docs are pretty Windows centric. You just gotta love screen captures of a DOS box. (We do things a little different in the Linux/Unix world where we can actually copy TEXT out of a command line easily.)

After following how to export the certificate out of Firefox, I had a P12 file. My experience was something like this:

wget  http://wiki.austriangrid.at/files/PKCS12Import.java
javac PKCS12Import.java
java PKCS12Import srcbin-code-signing-certificate.p12 keystore.ks
jarsigner -keystore keystore.ks classes.jar "srcbin, inc's the usertrust network id"
jarsigner -verify -certs classes.jar

(Or maybe I should show you that in 4 or 5 screen shots, put in a document and covert it to PDF)