Embedded Systems September 2000 Vol13_10

Issue link:

Contents of this Issue


Page 169 of 229

The first rule of using an SCM tool is to do all development work within the provided workspace. recreated from one day to th e next, given identical inputs and tools. In more direct terms, if one has to check out a fil e to be able to reproduce a build, something is being incorrectly version controlled . ome items that may not be obvi- ous, but nevertheless should be placed under CM are the scripts used to invoke the tools. Likewise any com- mand-line options passed to the tools should be placed in directive fil es passed to the tool, which can then be placed in the SCM database. This leads to the first rule of main taining a build process: Source+ Tools= Product The build process should be cast in stone with no room for deviation. Any and all command-line options should be in some form of fil e passed in with the command-lin e. The steps of calling each tool and script should be in batch fil es as much as possible. Ideally, one command typed at the command-line will execute every step necessary fo r creating th e exe- cuta bl e. Anything that canno t be automated in some kind of script should be fully docume nted in th e CM plan (discussed later ). The test of a good build process is: "can an engineer not on the developme nt team recreate th e product your team is developing?" As a matter of completeness, any proj ect-related documentation should also be placed under version conu·ol. Just as reviewing the evolu tion of source code over the course of a pro- j ect is useful , reviewing the evolution of such things as requirements, designs, policies, and practices can also be useful. By placing these docu- ments in the SCM database, the ability to review where the proj ect has been from a managerial perspective is great- ly facili ta ted . Working in the SCM workspace • Always work within the workspace • Only use one workspace per unit of work • Keep the workspaces synchronized with the codeline The first rule of using an SCM tool is to do all development work within the provided workspace. Many engi- neers new to SCM prefe r to stick to the ir old habits of ad hoc SCM and develop their fil es in th eir own sub- directori es. Once th eir work is com- plete, th ey check out the fil es th ey changed, copy the ir personal fil es to the workspace, and check everything back in. This approach is fl awed in many ways. Part of the power of SCM is the history of a fil e it records as the file in crementally changes through th e course of development. 1 usually suggest that anything that compiles is ready to be checked in . Anyone in clined to develop out ide the SCM workspace is also going to be very reluctant to check in anything until it is 100% complete. The next flaw with such an approach is the risk to the proj ect should th e guilty developer be unexpectedly unavailable at a cri t- ical time. If th e develope r has his work spread ac ross multipl e sub- directories using various home-brew back-up naming schemes, the re is li t- tle chance another develope r will be able to step in and figure out what is the "correct" version with which to proceed. Next, each developer should use a unique workspace for each unit of work: problem report/ change request (PRCR), bug fix, or feature. If a devel- ope r i working on two separate PRCRs he should be using two sepa- rate workspaces. If two developers are working on the same unit of work, they should again have their own workspaces. Any exchange of fil es should only be done through the SCM 168 SEPTEMBER 2000 Embedded Systems Programming system via check-in. Sharing a work- space either between developers or among PRCRs can introduce confu- sion as to the sta te of files. The SCM tracks development by check-ins from the workspace. When multiple devel- opment efforts are taking place in a workspace, the ability to make distin c- tions a to which check-in was for which PRCR is compromised . In effect, become coupled. Lastly, develope rs should always keep the ir workspace synchronized with th e codelin e. I can attest that constantly re-synchronizing with an ever-changing mainline is difficult. It is like trying to hi t a moving ta rget, but to not do so is an invitation for e rror. It is quite a waste to spend half a day debugging some problem that has already been fi xed and made pa rt of th e lates t code lin e. Worse still , is to write code that works with- in th e constra ints of some oth e r module that has been redesigned or even removed . Furthermo re, to forego merging and syn chronizing un til all the developme nt work is complete doesn 't remove the necessi- ty of synchroni zation; it only puts it off until the end, when the work- space and th e codeline are most divergent. Growing the SCM database • Always have a mainline codeline • Branch when appropriate • Design the codeline before th e pro- j ect tarts Two approaches to codeline devel- opment are the mainline model and the fJTomotion model. The mainlin e approach has a single branch that evolves fo rever. It is the ultimate desti- nation for most (not necessarily all ) changes made in all the other branch- es. By vi rtue of that fact, the mainline approach creates a common poin t from which all new development will sprout. All developers know the main- line is the most up-to-date, and the best place to begin new work. the developme nt effo rts

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10