In *.ncrunchsolution paths in MetricsExclusions are absolute - IMHO they should be relative. We keep this file under source control, developers has different paths to their local workspaces, so we are getting conflicts all the time, and this conflicts aren't resolvable.
Another suggestion: MetricsExclusions could have children nodes - one node for file - and this children could be alphabetically sorted. This way automatic confilct resolution will have easier task.
Remco NCrunch Developer
#2002
25 May 2012 11:14 UTC
Yes, this makes good sense. Thanks for letting me know about the merge issues ... I'll see what I can do.
Remco NCrunch Developer
#2197
19 Jun 2012 04:44 UTC
For anyone interested, 1.40b has just been released including the change requested above. Metrics exclusions should now be using relative paths (as opposed to absolute), and are sorted alphabetically for easier merging.
Thanks
1.40b doesn't import MetricsExclusion from .ncrunchsolution saved in 1.39b format, so I have to set them manually again :(
I didn't noticed this before, but why this setting is in *.ncrunchsolution and not in *.ncrunchproject? If project is used in many solutions, it has to be configured many times.
1.40b doesn't import MetricsExclusion from .ncrunchsolution saved in 1.39b format, so I have to set them manually again :(
I didn't noticed this before, but why this setting is in *.ncrunchsolution and not in *.ncrunchproject? If project is used in many solutions, it has to be configured many times.
Remco NCrunch Developer
#2209
19 Jun 2012 08:18 UTC
Hi Marqus -
Yes, sorry, I needed to include it as a separate property to simplify the upgrade process (since the file references are now in relative rather than absolute form).
The data is stored at solution level more because of technical/design/ease-of-implementation reasons. NCrunch stores all code coverage information at solution level (i.e. in the .cache file), as the tests that cover a project may not be present in all solutions that use the project.
From a configuration perspective, storing the exclusions at project level does make more sense though. I'll have a think about it.
Cheers,
Remco
Yes, sorry, I needed to include it as a separate property to simplify the upgrade process (since the file references are now in relative rather than absolute form).
The data is stored at solution level more because of technical/design/ease-of-implementation reasons. NCrunch stores all code coverage information at solution level (i.e. in the .cache file), as the tests that cover a project may not be present in all solutions that use the project.
From a configuration perspective, storing the exclusions at project level does make more sense though. I'll have a think about it.
Cheers,
Remco
Post a reply
Log in to reply.