Reproducing old configurations with tracking info
One of the duties of configuration management is to be able to reproduce old configurations. For this purpose, configurations are baselined, labelled or committed. When you need the configuration, you just create a workspace that looks at the old baseline. Using branching, one could even make changes relative to the old configuration (if the CM system supports it).
Now surprisingly, to me at least, in the old configuration the supportive (meta) information is not reset to the old state. For example, the database of Defect records is not set to the old state. If we have solved a problem recently that was already known (and left unresolved) in the previous release, the defect remains in resolved state even though we have a workspace where the problem still exists. Isn't that plainly a wrong representation of the reproduced state?
If we then decide to resolve the problem on the old release, we need to make a new defect record. This new record will have a submission date after the release we try to solve it in although the problem itself was discovered before the release. Wrong representation of the truth again!
Wouldn't it be correct to have other (meta-information) systems support reproduction of old configurations and branching in the same way as the configuration management system does?
No comments:
Post a Comment