Mercurial .hgignore pour les projets Visual Studio 2010

À ne pas confondre avec les projets Mercurial .hgignore for Visual Studio 2008

Je me demandais si ce même fichier pouvait être réutilisé pour Visual Studio 2010, ou si d’autres extensions devaient être ajoutées, et pourquoi?

Les nouvelles choses sont liées aux choses MSTest. C’est celui que j’utilise:

# use glob syntax syntax: glob *.obj *.pdb *.user *.aps *.pch *.vspscc *.vssscc *_i.c *_p.c *.ncb *.suo *.tlb *.tlh *.bak *.[Cc]ache *.ilk *.log *.lib *.sbr *.scc *.DotSettings [Bb]in [Dd]ebug*/** obj/ [Rr]elease*/** _ReSharper*/** NDependOut/** packages/** [Tt]humbs.db [Tt]est[Rr]esult* [Bb]uild[Ll]og.* *.[Pp]ublish.xml *.resharper *.ncrunch* *.ndproj 

Je pense qu’il est important de connaître chaque élément d’information sur mes référentiels. Je ne copie donc jamais le fichier .hgignore d’un repo à l’autre, mais je le construis toujours au fur et à mesure.

C’est facile avec TortoiseHg, car la fenêtre Commit listera tous les fichiers non suivis, et un simple clic droit me permettra d’append des patterns pour ignorer ces fichiers. De cette façon, je découvre toujours de nouveaux fichiers que je peux ou non vouloir conserver.

Par exemple, dans la liste publiée par Thomas, *.resharper est la dernière entrée. Cela empêchera le partage des parameters de réaffectation par solution, car l’une des options de la boîte de dialog de configuration de ReSharper peut être définie sur. En d’autres termes, si vous voulez vous assurer que tous les développeurs fonctionnent avec les mêmes parameters pour beaucoup de choses avec lesquelles ReSharper vous aidera, cette ligne particulière ne peut pas être là.

Donc, mon conseil est le suivant: faites-le manuellement, vous apprendrez une chose ou deux sur votre projet.