What to Put Under Version control?

Well, the vague answer is that it depends on your specific needs. Some advocate only “Your Content”, like the BSP you’re developing, or the platform project you’re working on needs to be put under version control. The motivation usually is that since you should not change the contents of the original tree, this will remain constant over time, and you really only need to put the parts that you change or add under version control. The static part you can recreate by just reinstalling Platform Builder, should it be needed.

I, on the other hand, advocate that you should put everything under version control. Why? Well, this might come as a surprise to you, but software is known to contain bugs (!). Since Windows CE is no exception, Microsoft releases Quick Fix Engineering Updates, QFE:s, every now and then. When installed, a QFE updates and/or adds files to the build tree. In other words, the contents that is thought of as constant over time, is actually pretty volatile.

Now, if, or rather when, you get a tough to figure out bug report for a device that’s been on the market for a while it’s often a huge advantage to be able to recreate the exact build environment used for that particular image. Since all the compilers, linkers and other tools used to build the image resides in the build tree, version controlling the whole tree, you can just check out that version and voila, you’ve recreated that build environment. You’ll be able to look at the source code as it looked at the time the image was created, create some hacks to reproduce the bug, pin down a fix etc. Without the support from the version control system, It is just so much more labour intense and error prone to recreate a build environment, taking into account that you need to keep track of what QFE:s and rollups had been applied at the time of the build etc.

If you put the whole tree under version control you’ll not only ease product archaeology expeditions like the one mentioned above, you’re also making it a lot easier to maintain up-to-date, identical build environments for all team members. If their working copy is up to date, they’re good to go.

Sure, putting the whole tree under VC will take considerably more storage space and bandwidth, but since you get storage and bandwidth almost for free these days, it’s a really cheap insurance.

What not to put under version control?

Huh? I just said everything should go under version control, didn’t I? Yes, I did, and I stick to that –with the following exception; when sysgen:ing the image, there’s whole bunch of intermediate files created at various places throughout the build tree. These, you generally don’t want to put under version control (unless you can come up with a very good reason to do so of course!).

Cleaning up

A BSP:

As I said earlier the BSP resides under “…\WINCE500\PLATFORM\<some bsp>”.  The following files are intermediate files or otherwise unnecessary to version control:

• *.bif
• build.log, .dat, .wrn, and .err in root and subfolders
• all “….\OBJ\...” contents including the folders themselves
• all “…\lib\...” and “...\target\...” contents including the folders themselves
• “..\files\cesysgen” contents including the folder itself

A Project:

In the project folder, “%_PROJECTROOT%”, the following files are intermediate files or otherwise unnecessary to version control:

• “SysgenSettings.out"
• “build.*” in all root and subfolders
• "%PBWORKSPACEROOT%\%_TGTPROJ%.log", ".ncb", ".plg", and ".opt" files
• “\CeSysgen\” contents and the folder itself.
• “\Reldir\”, “\MakeSDK\” and “\SDK” contents and the folders themselves 
• all “...\OBJ\...” contents including the folders themselves