Embedded Systems September 2000 Vol13_10

Issue link:

Contents of this Issue


Page 171 of 229

Branching should be used only when incompatible policy exists for user's needs. Conversely, the promotion model abandons every branch once it is no longer needed. This creates a moving point fo r beginning new develop- ment- something i.hat may be diffi- cult to communicate. It also creates extra difficulty for developers to stay synchronized with the codeline. If the branch th ey were working from becomes obsolete, they must relocate all their work to some other branch. I also suggest that the mainline always have a fully working and tested build as its latest release. This gives all developers a known-good baseline to start whatever development effort they need. This is something that is impos- sible with the promotion model as the branch in which to start new develop- ment is always changing. Branching is, perhaps, the most controversial topic in SCM because everyone seems to do it differendy. SCM tools support branching in a myr- iad of different ways, and organiza- tions use branching in still a myriad more. My advice for branching is to branch only when absolutely neces- sary. Maintaining branches is a lot of work. Propagating changes from a branch to the mainline and back again is a never-ending chore. It is most pru- dent to keep all this effort to a mini- mum by just keeping branching to a minimum. Branching should be used only when incompatible policy exists for user 's needs. For example, the prod- uct release group wan ts a check-in policy that is very controlled and rig- Prom ICE The Leader in Memory Emulation • Ultra fast downloads. •Support for any memory. • Works with many de buggers. •Trace & code coverage. []] Grammar Engine Inc. l:l5ll Call Toll Free: 1-800-776-6423 . 170 SEPTEMBER 2ooo Embedded Systems Programming Cogent Computer Systems, Inc . Tel: 401-295-6505 • CMA COGENT MODULAR ARCHITECTURE orous. The marke ting research group wants a check-in policy that allows frequent, easy check-ins of nearly anything that compiles. While these groups may be working with the same source modules, their needs are radically different. Another example is th at of separate development teams using a common cod e base and creating common products, but fo r different marke ts. They may be working on the same product, but a Web-based Vehicle Registration Sys tem fo r the Commonwealth of Kentucky is going to have some radically different code than that for the State of Indiana. Don't copy when you should be branching. I have seen some engi- neers think they can avoid the effort and hassle of branching by just copy- ing. Copying has all the maintenance requirements of branching without the automatic merging support pro-

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems September 2000 Vol13_10