High-level Best Practice Six(6) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first five areas and there practices are already discussed.

Process

- Track change packages. Even though each file in a codeline has its revision
history, each revision in its history is only useful in the context of a set of related files. Change packages, not individual file changes, are the visible manifestation of software development. Some SCM systems track change packages for you; if yours doesn’t, write an interface that does.
- In order to make propagating logical changes from one codeline branch to another easy, tracking change packages has a benefit. However, it’s not enough to simply propagate change packages across branches; you must keep track of which change packages have been propagated, which propagations are pending, and which codeline branches are likely donors or recipients of propagations.
- SCM process should be able to distinguish between "What to do" and "What was done".
- Every process, policy, document, product, component, codeline, branch, and task in your SCM system should have an owner. Owners give life to these entities by representing them; an entity with an owner can grow and mature.
- The policies and procedures you implement should be described in living documents; that is, your process documentation should be as readily available and as subject to update as your managed source code.

High-level Best Practice Four(4) in Software Configuration Management

There are six general areas of SCM deployment, and some best practices within each of those areas. The first, second and third area and there practices are already discussed.

Change Propagation

Propagating file changes across branches needs to be managed. The practices involved with this work space are :
- Do not delay to propagate a change. When it’s feasible to propagate a change from one
branch to another (that is, if the change wouldn’t violate the target branch’s
policy), do it sooner rather than later.
- It is much easier to merge a change from a file that is close to the common
ancestor than it is to merge a change from a file that has diverged considerably.
This is because the change in the file that has diverged may be built upon
changes that are not being propagated, and those unwanted changes can
confound the merge process.
- Changes can be propagated by the owner of the target files, the person who make the original changes, or someone else.