After my new found love of all things Subversion, I’ve been trying to faff about obtaining that perfect config (instead of doing any actual coding!). There are a number of things in the TortoiseSVN settings that I’ve needed to change so far which have caused me a bit of bother maybe. That and I’d like to just point out a few cool things that you can find when digging around TortoiseSVN too.
Firstly, there is the two important settings you should heavily consider before you even start using SVN:

Some important settings for TortoiseSVN
The first thing of note is the big “Global Ignore Pattern” box. This is a space delimited list of files (with wildcards included) that can be used for excluding when you commit to your repository. The original set I left as it was, but added a few key additional files to that list:
*.o *.lo *.la *.al .libs *.so *.so.[0-9]* *.a *.pyc *.pyo *.rej *~ #*# .#* .*.swp .DS_Store *_ReSharper* *.suo Thumbs.db
The key ones you’ll spot I’ve added are *_ReSharper*, *.suo and Thumbs.db. I was keen to avoid putting all the ReSharper files in there by default, and this seemed like a good way of doing this. The *.suo was added when I realised that all I had to do was open the project and this file would change, a little look around shed the light that this file isn’t needed and can be dropped from SVN altogether. Thumbs.db (case sensitivity is important btw), was because I develop on a windows box and it seems intent on creating that damn file everytime I put an image in the directory – so I’ve excluded that too.
The tickbox at the bottom was a little bit more recommended, than something I’ve learnt from. When you have a nosey at the official documentation for TortoiseSVN, they do say that Visual Studio.NET has issues with the dot format SVN directory (Edit: This was only relevant for VS 2003 it seems (see Bert Huijben’s comment below) – so not much of a worry if you are on exclusively newer versions.):
VS.NET when used with web projects can’t handle the
.svnfolders that Subversion uses to store its internal information. This is not a bug in Subversion. The bug is in VS.NET and the frontpage extensions it uses. Read the section called “Subversion Working Folders” to find out more about this issue.If you want to change the behaviour of Subversion and TortoiseSVN, you can use this checkbox to set the environment variable which controls this.
You should note that changing this option will not automatically convert existing working copies to use the new admin directory. You will have to do that yourself using a script (See our FAQ) or simply check out a fresh working copy.
While this issue might have gone away (I never experienced it). It seems quite foolish to simply ignore this setting when it does explicitly say against it!
I’ll reserve this post for any future amendments to my standard settings – as much a reference for myself as anyone else.
Wooooo! Time to do some coding!
- The Layout of a Subversion Repository How I'm suggesting we layout or works Subversion repository and...
- Multiple Subversion Projects in one Visual Studio Solution using svn:externals I have a Visual Studio solution with two projects in...
- SourceSafe or SubVersion? Since time of yore, Microsoft Visual Source Safe has been...

Coding Horror



The ‘_svn’ issues are exclusive for Visual Studio 2002 (Original .Net) and 2003.
If you only use VS 2005 and later I would recommend not setting this checkmark. (But do keep it if you had it already set as resetting would break existing working copies)
Ahh, I must admit that I had erroneously not set it somewhere and hadn’t noted any ill effects. I guess I obeyed the warning too blindly.
I’ll update the post to reflect this, thanks!