If you’re using TortoiseHg, (if you’re not, you should stop reading now to go install it), your default installation should put your Mercurial.ini file in your %userprofile% folder.

Make your [ui] section edits to point to a file (name is up to you):

[ui]
...
ignore = %userprofile%\.hgignore
...

Finally, make sure you have an .hgignore compatible file. This is what I’m using right now:

syntax: glob
*.o
*.lo
*.la
#*#
.*.rej
*.rej
.*~
*~
.#*
.DS_Store
*.suo
*.user
*.webinfo
[Bb]in
*/[Bb]in
[Oo]bj
*/[Oo]bj
*.[Bb][Aa][Kk]
*.~??
*[Tt][Mm][Pp]
_vti_txt
*/_vti_txt
_vti_script
*/_vti_script
_vti_pvt
*/_vti_pvt
_vti_cnf
*/_vti_cnf
_private
*/_private
.~*
*.~*
[Rr]elease
*/[Rr]elease
[Dd]ebug
*/[Dd]ebug
[Aa]nkh.[Ll]oad
*/_ReSharper*
_ReSharper*
*resharper*
*.Cache
*.StyleCop
*.ReSharper
obj/
bin/
*.ncb
*.suo
_ReSharper.*
*.resharper.user

When using TDD, especially with utilities such as StuctureMap’s RhinoAutoMocker I tend to end up with some “childless” interfaces.

Granted, this could just mean I’m a crappy OO designer, but I like to think it’s more from hammering out the design as I’m working on the problem!

So, I might have a code base that has unused interfaces lying around, and I just want to clean those up.

With NDepend, you can use Code Query Language (CQL) to search for items of interest in your code base. Very cool.

Here’s the CQL for finding Interfaces that have no implementations.

[csharp] // <Name>Find interfaces without Derivatives</Name> SELECT TYPES WHERE IsInterface AND NbChildren == 0 [/csharp]

Sitting down to check out a copy of NDepend is very intimidating. You see, I’ve been intrigued by the product ever since reading Hanselman’s description of its capabilities. Scott also put up a cheat sheet of sorts to the metrics used in NDepend’s analysis.

Rather than a rehash, go check the article, another bang-up job by Scott. What is intimidating is all the analysis you can do with this tool, it makes you feel like you should be doing something smart with it.

For that problem, I can’t say I have a good solution for you. Perhaps if I was in charge of more than a handful of developers as a architect, and coded less frequently, this tool would feel more comforting to me. In my current capacity as a dev lead, working daily in .NET with a team of other senior dev’s, I haven’t quite entered that “Zone of Pain”.

One thing I give kudo’s to the NDepend team for is their Videos and Tutorials and comprehensive help. Clearly I’m not the only one some confusion on how to make the most of this tool and it’s great to know that the product team has put serious work into making the tool discoverable and useful.

Check out this Welcome Screen:

Notice the real estate devoted to “Getting Started”, a very nice touch.

Another nice feature, is an ability to call out NDepend from Visual Studio and Reflector, which is my normal code exploratory/analysis tool.