Самый простой способ - использовать внешний инструмент сравнения в этих двух представлениях (например, WinMerge или BeyondCompare в Windows, KDiff3 в Unix или Windows, ...).
Я бы фактически создал два новых представления (с той же конфигурационной спецификацией, что и у двух начальных представлений), чтобы удалить любой эффект "кэширования" и начать сравнение там.
После того, как этот первоначальный пример сделан, я бы начал компиляцию в этих двух представлениях и посмотрел, не скомпилировано ли одно из них.
Не забывайте, что слияние A с Main не всегда приводит к тому же набору файлов после слияния.
Это было бы то же самое, только если в Main не происходила эволюция с момента начала A (или с момента последнего слияния с A до Main).
setcs -current, о котором вы упомянули, будет:
–cur/rent
заставляет view_server очищать свои кэши и переоценивать текущую конфигурационную спецификацию, которая хранится в файле config_spec в каталоге хранилища представления. Это включает в себя:
- Оценка правил времени с неабсолютными спецификациями (например, сейчас, вторник)
- Переоценка - настройка правил, возможно, выбор других производных объектов, чем ранее
- Перечитывание файлов, указанных в include-правилах
Если вы зависите в своей конфигурации от «включаемого файла», который был неправильной версии, первый setcs установил бы его в правильной версии, а второй прочитал бы его содержимое и установил правильную версию для остальных .