Importing the tree

The easiest way of putting the correct files under version control is to import a fresh PB install in which nothing has been built yet. If you’ve built projects already, you should either scrap the tree and start over (i.e. reinstall), or you can try to filter out or delete the intermediate files created during a build as described before.

After you’ve checked in the "squeeky clean" tree, you naturally go right to Microsoft’s download site and download all relevant rollups and QFE:s. I’d probably apply the rollups and QFE:s, one by one, checking in the changes after each install, meticulously logging each installed package. However, if you’re not really interested in this level of record keeping you can apply all the QFE’s and rollups to this date before actually importing the tree. I’ll leave it up to you to decide.

Use a vendor branch

I prefer to keep the “clean” build tree, “Their content”, in what is known as a vendor branch. A vendor branch is a CM-pattern used to handle 3:rd party resources that your project is closely related to, or perhaps dependent upon. Generally, the needs of your project will dictate that you stay as up-to-date as possible with the resources provided by that 3:rd party vendor without jeopardising the stability or feature set of your own project. The vendor branch is an elegant solution to this problem.

When using a vendor branch, updates from the 3:rd party vendor (usually dubbed “vendor drops”) are absorbed into a branch separate from your project’s branch. The vendor branch is then merged into the project branch when the project is ready to absorb the vendor drop. Once merged into the project branch, the code can be patched and altered to your liking in the project branch, without polluting the original vendor drop with project specific mutations.

In our case, Microsoft is the 3:rd party vendor, and a QFE or a rollup update will be a vendor drop. It might seem like overkill to use this approach, especially since altering any file provided by Microsoft is considered bad practice. Rather than altering the file directly, you should always clone the file and alter the cloned version leaving the original as is.

While cloning is doable in almost all cases, I have found a couple of rare exceptions where it is not possible, or at least next to impossible to tie everything together without having to alter Microsoft’s version of a file. One example is if you need to modify certain parts of GWES, such as “oomui.lib”. This modification involves altering ”winceos.bat”,  which is not easily cloned and thus you need to alter it directly.

So, because you can’t guarantee that it is always possible (or that you're skilled enough) to duplicate the code in every case, I advocate the use of vendor branches, which separates the changes made to the tree by Microsoft, and the changes made specifically for your project.

A decent version control system will detect any alterations made in the project branch since last vendor branch merge, so the possibility to overwrite any  project specific changes done to the vendor specific contents by mistake is practically eliminated. Had the vendor drop, (i.e a QFE) been installed directly onto a working copy of the project branch and then checked in, conflicting changes might have been overwritten by the QFE install. Not good.

The vendor branch pattern can also be used to manage other 3:rd party code such as a 3:rd party BSP. Normally, each 3:rd party package should have its own vendor branch, so you can control the updates independently from one another.