We were having a problem with our build server not checking out modifications from source control despite recognizing that there had been changes.
It was traced to the control folder (not sure what it’s real name is), the existing working builds were using _svn. Clearing the working folder forced a new complete checkout and I noticed that now the control folder is .svn. It looks like originally our integration routines were checking out code using _svn but now it is using .svn.
The svn.exe being used during integration is from VisualSVN Server can I set this up to use _svn again?
How the original working copies were using _svn I don’t know! – we only ever ever used VisualSVN Server and haven’t changed this.
We had setup TortoiseSVN to use _svn following the recommendation that this works better for Visual Studio and have also installed TortoiseSVN on the build server in case it is ever needed. Could this be the cause?
Also is this really necessary? As MSBuild is Microsoft’s is it recommended as it is for Visual Studio?
The business about _svn vs. .svn was an issue with Visual Studio web projects only (and I’m fairly sure it was fixed in VS2005 anyway), it’s not a general ‘_svn works better with VS’ thing.
It’s also only a working-copy issue, not a repository issue – i.e. it doesn’t matter if some users of SVN are using clients set up to do _svn and some are using .svn – the repository won’t know or care – (unless somehow you end-up with a load of these _svn/.svn files actually checked-into the repository which would be confusing in the extreme.)
Unless you have absolute concrete evidence that .SVN is causing you problems, then I would stick with that wherever you can.