The main issue with using path names for identifying configuration items is that path names are attributes of configuration items and thus, can also change. Assume for example that directories represent subsystems (e.g., storage, notification, user interface, train tracking). In the case of a change of the subsystem decomposition, the directory structure may change (e.g., the storage directory may be split into a database directory and a JDBC directory). For tools which use path names as identifiers, this translates into configuration items being deleted and added under a different path name. Since different versions of the same configuration items have different identifiers, operations such as merging branches are consequently not possible.

Question

What will be an ideal response?

Answer 1

Scenario 1: Assume developers work on new features sequentially and create new versions of the systems as a feature
becomes stable. Assume the current version is n and that versions m through n contain partial implementation of the
latest feature F. The implementation of F unfortunately, introduces many issues and developers decide to rethink their
approach. They find a better way to implement F, however, it requires them to undo all changes related to F. When
using a version control tool and the sequential configuration management policy described before, this can be simply
done by checking out version m-1 and discarding versions m through n.
Scenario 2: Branches can be used to manage the development of concurrent features. If the implementation of all
features succeed, the branches need to be merged. If the development of one feature fails as in scenario 1, the
corresponding branch can be ignored while the rest of the development proceeds.