Add an OS Design to a Source Control System (Compact 7)
3/12/2014
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 is required to define the project, you can enjoy the benefits of source code control while keeping the source control system manageable. After building an OS design, your set of project files might total over 1 or 2 gigabytes (GBs) in size. It is not practical or necessary to store all these files in the source code control system. Most of the files in an OS design are build artifacts that will be regenerated during a build.
This article discusses which OS design files you must add to a source control system to share your project with team members. This article does not address any particular source code control system, nor does it address scenarios such as trying to share various build artifacts to reduce build times.
Prerequisites
This article assumes that you have an OS design for a Virtual PC x86 board support package (BSP) that uses the Enterprise Device Handheld design template. However, you can apply the steps in this article to any OS design template and BSP.
Step 1: Add the Solution File to Source Control
The first file that you must add to a source code control system is the solution file (for example, <Solution Name>.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: Add the Project Files to Source Control
Where you add the remaining files in the source code control system depends on whether you selected the Create directory for solution check box in the New Project dialog box in Microsoft Visual Studio 2008. If you selected this check box, a subfolder with the same name as your project is created in the directory where your solution file is located. Navigate to the directory contains the following files, and add only these files to the source control system:
- CEBASE.bat
- OSDesign.bib
- OSDesign.dat
- OSDesign.db
- OSDesign.reg
- postWINCE.bat
- <Project Name>.pbxml
You do not have to add the following files and subfolders to the source control system:
- \RelDir
- \SDKs (this folder exists only if you generated an SDK for your OS design)
- \Wince700
- <Project Name>.pbxml.user
The <Project Name>.pbxml.user file contains settings that are unique to your development environment, so you should not share that file with team members.
The RelDir and Wince700 subfolders are not needed. The contents of these subfolders will add over 1 GB of files to the source code repository that do not have to be stored because they are intermediate files generated as part of the build process.
If you have a set of SDK configuration files, you can add those to source control. You do not need the SDK installation file (.msi) because it can be generated by the configuration files.
Step 3: Add the Source Code Files
Next, add the source code files that you are contributing to the OS design, such as driver files or application subproject files. Instead of adding thousands of megabytes in irrelevant files, you only have to add required files, and you can omit Obj and Bin folders. By using 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 explicitly checks out a file. This will affect your solution (.sln) file in particular, in addition to any other file that you indirectly modify when you change your OS design. To work around this issue, check out these files before you change the files, and make sure that you 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.