The simplest way is to use an external diff tool on those two views (like WinMerge or BeyondCompare on Windows, KDiff3 on Unix or Windows, ...).
I would actually create two new views (with the same config spec than the two initial views), to remove any "cache" effect, and start the comparison there.
Once that initial examen is done, I would start the compilation in those two views, and see if one of them still don't compile.
Don't forget that merging A
to Main
will not always result in the same set of files after the Merge.
It would be the same only if no evolution has taken place in Main since A
started (or since the last merge from A
to Main
).
The setcs -current
you mention will:
–cur/rent
causes the view_server to flush its caches and reevaluate the current config spec, which is stored in file config_spec
in the view storage directory. This includes:
- Evaluating time rules with nonabsolute specifications (for example, now, Tuesday)
- Reevaluating –config rules, possibly selecting different derived objects than previously
- Re-reading files named in include rules
If you depend within your config spec on an "include file" which was at the wrong version, the first setcs would set it at the right version, and the second one would read its content and set the right version for the rest.