EETimes

Embedded Systems September 2000 Vol13_10

Issue link: http://dc.ee.ubm-us.com/i/71837

Contents of this Issue

Navigation

Page 168 of 229

Another useful debugging technique CM provides is the ability to try out and test prior executables for the presence of a newly discovered bug. true when a unit stops responding altogether. By having the abili ty to back up and try a previous, "known- good" executable, you can quickly determine whether the hardware or software is at fault. Another useful debugging tech- nique CM provides is the ability to try out and test prior executables for the presence of a newly discovered bug. If the bug can be characterized as exist- ing in one executable (Y), but not in the executable immediately prior (X), you know the bug resulted from the set of changes that made executable Y different from executable X. For software already in produc- tion, once a bug has been located, the affected executables must be identi- fied, and, depending on the circum- stances, customers notified. This problem is somewhat similar to batch manufacturing processes. If a defect is found, all affected products must be located and repaired or replaced. As a result, manufacturers use prod- uct ID code to track all products that are of the arne batch. SCM tools make use of version numbers and release labels to track and identify products. This abili ty may be a non- i ue for team and organizations that develop a single product from a sin- gle code base. However, for engineers developing multiple, closely related products, this capability is extremely useful. It allows them to use a single code base as much as possible while still being able to know exactly which source modules were used to create any given product. When a bug is found in a source module, the engi- neers are able to know which exe- cutables are affected. Another great advantage of SCM is the way in which it aids and encour- ages developers to work together. Because SCM tools can maintain mul- tiple environments for reading and editing files, they allow developers to work on a set of files without immedi- ate concern for the work of other individuals on the team. While a developer is doing the work of editing and compiling code, only the changes he makes will be reflected in his devel- opment environment. This allows every engineer on a team to indepen- dently make changes to the same file at the same time. Once each of them has completed making and testing all the modifications that need to be made, they can one by one put their completed work back into the CM system. The SCM will automatically synchronize all orthogonal changes. Wherever a conflict arises, the SCM will stop the automatic synchroniza- tion and prompt the user for manual intervention. Another manner in which SCM assists developers working together is that it allows each team member to view the other members' work. When one developer is about to make changes to a file , he can immediately see if anotl1er developer is working on the same file . Once tl1e other develop- er has finished making changes, and added tl1em back into the SCM data- base, the first developer can easily compare the new version to the old version and see the exact nature of the changes. Maximizing effect Like any tool, SCM should be used on the problems it was designed to fiX and in the manner is was designed to operate. To truly gain tl1e benefits mentioned in the preceding para- graphs, SCM must be used in a planned, organized method. What fol- lows is a compilation of common sense practices to using SCM that are often obvious only in retrospect. What should be under version control? • Source files • Makefiles • Scripts • Associated documentation The first question any SCM user has to answer is: "what should be ver- sion con trolled?" Strictly speaking, anything that is an input to the process of creating your product should be version controlled. However, I would add the following caveat: tools from outside the organi- zation tl1at are not expected to change over the course of the project should not be version controlled. For exam- ple, your compil er, linker, and debug- ger are static over the course of the average project. Therefore, I would not put them under SCM. I do suggest that they be archived in some fashion, but they will not need tl1e amount of rigor that an SCM tool provides. There is a gray area for tools that are developed inside the organization, but by other teams or groups. You are the one best able to evaluate tl1e other groups in your organization. What level of trust do you place in their products and procedures? The easiest solution is when the other group is using SCM (they should be) and you can get to their code. In this case it should be adequate to merely add their source files to your workspace in some fashion such that there is no doubt as to which version of their product was used to assist in creating your product. Intermediate products hould not be placed in SCM. The most obvious intermediate products are object files. Though they are inputs to the linker, they are products of the source files and compiler. The litmus test for when something is an inter- mediate product is whe ther it can be Embedded Systems Programming SEPTEMBER 2ooo 167

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10