Configuring VisualSVN Server to use _svn instead of .svn

Question

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?

Answer 1

I've been using .svn with Visual Studio 2008 and 2005 as well as on our CC.Net integration server (with MSBuild) with no issues. I'd stick with the .svn format.

Answer 2

As far as I know _svn is needed, because WebApplications have problems when one of their directories begins with a point.

Answer 3

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.

Answer 4

Found this link which may be useful - mentions the environment variable SVNASPDOTNETHACK - possibly not set ??

http://subversion.tigris.org/svn_1.3_releasenotes.html

Need to read the "Official support for Windows '_svn' directories (client and language bindings)" section

Answer 5

http://subversion.tigris.org/svn_1.3_releasenotes.html

Need to read the "Official support for Windows '_svn' directories (client and language bindings)" section

And need to be aware that you're reading documentation which is several years old, a fact which might or might not be pertinent.