As I mentioned here, Phoenix has a relatively unique version control system to take care of the roughly 240,000 assembly-language source files in our TrustedCore code base. Not only does this lead to problems when synchronizing 14 different development sites around the world, it also leads to problems when creating version labels.
Every file archive in TrustedCore has a revision. A revision is just a number which uniquely identifies a set of changes made to one source file. A version label is used to record the revision of every file archive in TrustedCore at a particular moment.
Usually we generate several labels as we move towards a major new release of TrustedCore, 'A', 'B', 'C' etc. Our BIOS Production team creates the labels, and then the Quality Assurance folks use that version label to retrieve retrieve the exact revision of every file in the release. They put it through its paces, find bugs, report bugs and then engineering fixes bugs. At some point, the BIOS Production team creates a new label and we start the cycle again. After the bugs are all cleared, that label is declared "Gold" and we release the product.
So most old-school version control systems (like CVS or PVCS) add the labels directly into the file archives. That is, the piece of data which says: version label X = revision level Y is inserted directly into the archive. That means that every single archive must be read, modified and written. That's 240K files on the network. Generating a label can take days (literally) this way.
In order to speed up this vital process, Phoenix created DFLs (Directory File List). In each directory of TrustedCore, there is one file which just lists the current revision levels of every source file. Every time we want a new revision of a file archive to be included in a label, we update its entry in the DFL.
This seems like kind of a hassle (and it is). But they payoff is that, instead of having to add the label to all 240,000 files, we only have to apply the label to 23,000 DFLs.
But wait! It an effort to create infinite levels of regression and save even more time, we have lists of lists, called CDLs (Component Directory Lists). These files just list the current revision levels of every DFL. Every time we want a new revision of a directory to be included in a label, we update its entry in the CDL.
So now, instead of having to add the label to all 23,000 DFLs, we only have to apply the label to 350 CDLs.
This approach needs Phoenix special tools to keep the grunt work down, but it helps a lot a crunch time when we're about to do a major release.
Next time we'll talk a little bit about how the BIOS comes together for one platform.
Tim
Comments