The unmerged files viewer lists any files that were candidates for a merge (because they matched the source pattern in at least one merge rule), but where a unique merge target was not found. As such, this is the primary viewer when it comes to identifying (and resolving) exceptions to general rules.

If there are no merge rules defined, the list will be empty.

Let's suppose that the user then defines a single (bad) rule as follows:

Merge */*.h to */*.cpp // bad

With this rule in place, every single .h file in the code-base will be identified as a potential merge source. However, as long as there is more than one .cpp file present, the rule is too vague to uniquely identify the merge target for any given file. Accordingly, this viewer will be populated with the set of all .h files.

In general, there are 4 ways to deal with exception cases:

• Add a new (generalized) merge rule
• Modify existing rule(s) to be more specific
• Where appropriate, define do not merge or follow rule(s)
• Select individual exception cases and use the Merge candidates viewer to define specific rules

The ideal scenario is that there are no exceptions at all at a given point in time, and that the rules are sufficiently generalized that they will continue to apply in future as the code-base evolves.

See also: Hierarchies