With a number of different pattern-based operations acting on file names, it may be useful (or even essential!) to understand the processing sequence.
- The first step in the load sequence is to read the raw file names from the data file and check for a virtual rename in the name map (if this option is enabled). If found, all subsequent operations (except source viewing) will be based on the virtual name.
- Next, the load job checks for pre-transformations ("File names" section in the project properties). These work in exactly the same way as normal transformations except that they are applied earlier in the processing sequence - this is particularly handy for truncating long file names and normalizing away any version specific aspects in the directory structure. As above, if a pre-transformation applies, then all subsequent operations will be based on the transformed name.
- The next step is to check the excludes. If the real name of a file matches any exclude expression, that file (and all its contents) will be completely ignored.
- The next step is to check for merge rules.
- The final step in model creation is to apply any transformations and then infer the (directory) hierarchy.
It is worth noting here that any changes to the first four of these require a complete refresh of the project (including re-loading the raw data) to take effect. Transformations, on the other hand, can be edited on-the-fly and only trigger regeneration of the hierarchy (and associated metrics values).
Confusingly, however, it is possible to edit merge rules almost completely on-the-fly. This is because the merge perspective only simulates the effect of rules rather than actually executing them on the full model. For this reason, once you are happy with your rules, you need to choose Project/Refresh if you want to see the effect of the rules in other perspectives. Note also that, given the processing sequence outlined above, merge rules need to be based on the names of the files before the (final set of) transformations are applied.