Monday, April 25, 2011

What Visual Studio files should be ignored by subversion to eliminate or conflicts?

I am supporting a number of .Net developers who are using Subversion to version control their work, but we have been running into a number of issues that seem to revolve around the additional files that Visual Studio uses to manage projects, do debuging, etc. Specifically, it seems that these files are causing conflicts due to the fact that they are already in the repo. I know how to get them out and how to handle them, but I need to know what "they" are first.

So, what are the files/directories that Subversion can ignore, and why can they be ignored?(aka. what do those files do?)

This is a large, rather un-organized ASP.Net site and deploying the site is done via. svn updates, so files needed by IIS to dynamically compile (I think that's what it is) the site as files change needs to be left in the repo.

From stackoverflow
  • I would probably say anything in the bin directory.

  • AnkhSVN does a great job of only checking in the files that are necessary to the project.

    cdeszaq : Do they have a list anywhere?
    Bert Huijben : AnkhSVN 2.0 doesn't use a list of what to ignore. The project provides a list of what should be added to its SCC Provider, in this case AnkhSVN. And AnkhSVN only suggests adding these files. (A user can override these settings; but normally you shouldn't)
    Sander Rijken : Can you fix your link (to http://ankhsvn.net or http://ankhsvn.open.collab.net/)? The project moved away from the tigris site.
    • bin and obj directories
    • *.user files (MyProject.csproj.user)
    • *.suo files
    • 'bin' directory is a good start (as @Kevin says).
    • You would do well to ignore the 'obj' directory too.
    • *.suo and *.user would be best left out of source control.
    • *.VisualState.xml is going to be personal choice too.
    • TestResults.xml (if you're using NUnit)
    • *.bin
    • *.obj
    • *.exe
    • *.dll
    • *.pch
    • *.user
    • *.suo
    • *.tlb
    • TestResults (VSTS unit test directory)
  • In addition to the ones people have suggested above, I frequently have to ignore *.cache because for some reason I don't know Resharper likes to put it's .cache files in the same folders as the code I work on. Also, I don't think anyone has mentioned *.pdb yet.

  • I have had good luck with this global ignore pattern:

    *bin *obj *suo *.user *.tmp *.TMP 
    *resharper* *Resharper* *ReSharper* *.Load *.gpState 
    Thumbs.db *.~m2

    I am running the Resharper plugin, so you can probably ignore that. ".~m2" is for a temporary file my data modeler creates.

  • I think a better question would be "What files should I add to Subversion?"

    The AnkhSVN 2.0 Subversion integration asks exactly this question to all the projects in your solution. (This question is one of the key parts of the SCC specification.) It will then only suggest adding these files.

    As user you can add other files manually (or mark some of the files suggested as ignored), but this behavior makes it very easy to do the right thing.

    Most other subversion clients don't have the luxury of talking to a system that really understands what should and shouldn't be added. (E.g. External clients like TortoiseSVN and its frontends can just guess based on file extensions).

    cdeszaq : So then, is there a way to determine this from outside of Visual Studio? Ankh doesn't meet all of our needs, and for some reason doesn't play nicely with how we structure things, so we can't rely on it to do this.
    Bert Huijben : The only way to talk to VS projects as an SCC provider is 'as an SCC provider'.. and that can only be done from inside VS.. If you have specific usecases that aren't handled by AnkhSVN you should tell us on the ankhsvn user list (or uservoice page).. otherwise there is not much we can fix:)
  • Here's my Tortoise global ignore:

    *.suo *.resharper *.sln bin obj *.user *.suo Debug Release .pdb test. ReSharper.* *.scc *.vssscc *.vspscc

    The last 3 help when you transition from visual source safe

0 comments:

Post a Comment