Home arrow Articles arrow Version Control Strategy for Windows CE Platform Environments
Version Control Strategy for Windows CE Platform Environments Print E-mail
Written by Henrik Viklund   
Article Index
Version Control Strategy for Windows CE Platform Environments
What to Put Under Version Control
Importing the Tree
Creating a Working Working Copy
Other Considerations

Creating a Working Working Copy

OK, so now you’ve got the tree under version control. Now it’s time to set up a working copy that will actually work!

File permissions

As you probably know, it is common for version control systems to manipulate the read-only attributes of the files under version control. Unfortunately some tools used during a sysgen don’t cope very well with read-only files. For example, it can be that the build system needs to replace a file with a localized version of it. This mean that if you have a version control system that sets read-only attributes on files, you need to handle this and remove the read only attributes for these files. If you don’t do that, the build system will complain with some not-that-obvious errors when trying to sysgen your working copy.

Basically you have two choices. Either you setup your VC system to place these files as read/write in the working copy, or you need to make them read/write in some other way.

The problematic files

So what files needs to be writable then? Usually, read/write-enabling “*.res”  in the directories and subdirectories listed below will get you off the hook. Under special circumstances "*.lib" and "*.pdb" contained in theese directories may also need to be writable, but I advice you to start only with "*res":

%_WINCEROOT%\public\common\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\datasync\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\dcom\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\directx\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\directx\sdk\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\gdiex\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\ie\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\ostest\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\rdp\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\script\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\servers\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\shell\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\speech\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\sqlce\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\wceappsfe\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\wceshellfe\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\viewers\oak\lib\%_TGTCPU%\%WINCEDEBUG%\
%_WINCEROOT%\public\voip\oak\lib\%_TGTCPU%\%WINCEDEBUG%\

Actually, not all files may need to be writable, but I'll leave it as an excersise for you to figure out exactly what files you need to modify the permissions for.

Brute Force approach

OK. An ugly problem calls for an ugly solution. If you can’t get your VCS to relax the read-only attributes for the files mentioned above in a controlled manner, you might be able to use a batch file to brute-force the read/write permission on the files. Preferably you put it as a “pre-sysgen” custom build action. It will run through the offending files and remove any read-only attributes on them. If your VCS is smart and checks these permissions before updating the working copy (like for example Perforce), you also need a way of reverting to the read only attributes or the VCS will complain (hint: use a "post-sysgen" script). An example batch file may look something like this:

attrib -R %_WINCEROOT%\public\common\oak\lib\%_TGTCPU%\%WINCEDEBUG%\*.pdb
attrib -R %_WINCEROOT%\public\common\oak\lib\%_TGTCPU%\%WINCEDEBUG%\*.lib
attrib -R %_WINCEROOT%\public\common\oak\lib\%_TGTCPU%\%WINCEDEBUG%\*.res /S
attrib -R %_WINCEROOT%\public\datasync\oak\lib\%_TGTCPU%\%WINCEDEBUG%\*.pdb
attrib -R %_WINCEROOT%\public\datasync\oak\lib\%_TGTCPU%\%WINCEDEBUG%\*.lib
attrib -R %_WINCEROOT%\public\datasync\oak\lib\%_TGTCPU%\%WINCEDEBUG%\*.res /S
… (and so on for all directories)

As you’ve probably figured out, using a batch file to modify the permissions is a quick n’ dirty solution, so you should try to avoid it and let the VCS handle it if possible. 



 
< Prev   Next >
Advertisement
Microsoft Windows Embedded Partner