Introduction
Adding your Windows Embedded Compact 7 OS design to a source code control system might be intimidating when you consider the number of files that appear to be involved. This article discusses which OS design files you need to add to a source control system
to share your project with team members. Knowing which files to add to the source control system allows you to
share your project without adding thousands of MBs in irrelevant files to your source code control system.
The scenario I discuss in this article is an OS design for a Virtual PC x86 board support package (BSP) that uses the Enterprise Device Handheld design template. I will discuss the essential set of files you need to add to your source code control system so the project can be shared. I will not address a particular source code control system, and I will not address scenarios such as trying to share various build artifacts to reduce build times.
Adding Files to Your Source Code Control System
After building an OS design, your set of project files might total over 1 or 2 GB in size. It isn't practical or necessary to store all of these files in your source code control system; most of the files in an OS design are build artifacts that will be regenerated
during a build.
For the purposes of discussion, assume that an OS design that targets a Virtual PC x86 BSP, using the Enterprise Device Handheld design template and all the default options, is located at C:\Article.
Step 1: The Solution File
The first file you must add to a source code control system is the solution file. In my example OS design project, this file is named For the purposes of discussion, assume that an OS design that targets a Virtual PC x86 BSP, usi-family:'segoe ui',sans-serif;color:#333333;">Article.sln. The solution file describes the contents of the solution and is located in the directory in which you created your OS design.
Step 2: The Project Files
Where you add the remaining files in your source code control system depends on whether you selected the Create directory for solution check box in the New Project dialog box. If you selected that check box, a subdirectory with the same name as your project is created in the directory where your solution file is located. For example, in my solution this subdirectory is named C:\Article\Article. Go to this subdirectory. You will see the following files and subdirectories:
\RelDir
\Wince700
<Project Name>.pbxml
<Project Name>.pbxml.user
CEBASE.bat
OSDesign.bib
OSDesign.dat
OSDesign.db
OSDesign.reg
postWINCE.bat
Add all the files in this directory except <Project Name>.pbxml.user to your source
code control system. The *.user file contains settings that are unique to your development environment, and you should not share them with team members.
You do not need to add the RelDir or Wince700 subdirectories to your source code control system. Adding the contents of these directories will add over 1 GB of files to your source code repository that don’t need to be stored because they are intermediate files generated as part of the build process.
Step 3: Add Your Source Code Files
Next, add the source code files that you are contributing to the OS design. Instead of adding thousands of megabytes in irrelevant files, you can add only a handful of essential files, listed in Step 2, to your source code control system. With these files other team members can sync the project to their copy of the OS design project and rebuild it.
Read-Only Permissions
Many source code solutions assign read-only file permissions to source code files until someone checks out a file. This will affect your solution (.sln) file in particular, in addition to any other file that you modify when you change your OS design. To work
around this issue, simply check out these files before you make changes to the files, and be careful to check them back in so team members will be able to sync those changes to their copy of the OS design project.
When you build or modify the OS design, if an error message indicates that the integrated development environment (IDE) is not able to write to a file, check out the file and try your action again.
Conclusion
When you put your OS design files into a source control system, you can exclude irrelevant files that would add thousands of MBs to the source code repository. By carefully selecting and adding only what you need to define the project, you can enjoy the benefits
of source code control while keeping your source control system manageable.