Local vs roaming configuration of NCrunch project and solution files

I noticed that the *.ncrunchproject and *.ncrunchsolution files contain both locally necessary information as well as sharable information. We would like to share the configuration through our Mercurial concurrent version control system, but every time someone makes a change in (locally) ignored or filtered tests, this is saved in the *.ncrunchproject files.

I would like the parts that are required for proper compilation, like additional includes and other project settings, to be shared among our programmers, but I would like localized settings that will change on each testrun, like filters and ignores, to be only available locally.

Visual Studio uses a separation with the *.user files for solutions and projects, does NCrunch offer something similar, or do you know of a best practice way of achieving the same effect (I am thinking of externally parsed entities, or some other way of splitting up the XML config files)?

There is a popular feature request that would probably capture this - http://ncrunch.uservoice.com/forums/245203-feature-requests/suggestions/5652744-separate-ncrhunch-project-configuration-from-user.

The original idea behind the 'Ignored Tests' feature was for it to be used to specify tests that wouldn't work with NCrunch. Such settings were ideally shared between team members as it would be annoying for them to need to each re-flag the tests that NCrunch couldn't run.

NCrunch does have a user only file (ncrunchsolution.user), which is basically a binary file containing non-critical configuration such as tool window layouts and the currently selected engine mode.

See here for a list of files created by NCrunch and what these files represent.

The Engine Modes (with their filters) are stored in the shared solution configuration file (ncrunchsolution), but the currently selected engine mode is stored in the local file (ncrunchsolution.user). This makes it possible for you to have your own Engine Mode (or set of engine modes) that you use for your work style - and others can use this if they choose to.

The main problem with NCrunch configuration is that where this configuration should be stored and how it should be applied seems to depend very much on how people are using the product. This makes it impossible to create a static design that can cater for all needs. The ideal solution is to introduce additional complexity into the configuration system to allow many of the settings to be specified on a user or team basis, with support for inheritance etc. I'm fairly certain that this will be introduced - though at this stage I can't promise when it will happen.