I’ve been struggling for a while now with a block in Subversion, a well-known issue that is really quite annoying. The proposed fixes work fine for various situations, provided that you remember to not create a web project in Visual Studio (or inherit them), or that you never use anything but TortoiseSVN (an incredibly nice tool).
I can’t do either. While I could go through a number of web projects and patch them up, I can’t ensure that another developer won’t just start a new project that way. And sure, using the TortoiseSVN client that has been modified to produce _svn folders (versus .svn) is convenient, but there’s a problem: using NAnt to bootstrap–either using the <exec> task, or the <svn-x> tasks from NAntContrib–will end up using the svn.exe, and the value of using the modified TSVN client is gone.
So, I poked around in the docs for TSVN, and found out that you can run the client from the commandline, TortoiseProc.exe. So my bootstrap target now looks something like this:
<target name="bootstrap">
<echo message="Updating from Subversion" />
<if test="${directory::exists(‘_svn’)}">
<echo message="Using TortoiseSVN"/>
<exec program="c:program filestortoisesvntortoiseproc.exe"
commandline="/command:update /path:. /notempfile /closeonend"
basedir="${project::get-base-directory()}"
failonerror="false"/>
</if>
<if test="${directory::exists(‘.svn’)}">
<echo message="Using NantContrib SVN task"/>
<svn-update destination="${project::get-base-directory()}" uri="svn://some-uri"/>
</if>
</target>
Why the two approaches? The build server does not have VS installed, and so the .svn folder issue will never come up. On the development machine, though, it might be nice to test out changes to the bootstrap and build scripts before checking them in (seriously, test before checking in?)
I ran into a minor issue that I logged with the TSVN folks–the exec task has a return code of 1 even on success. That’s why the failonerror=”false”. I will post an update when I hear back about the issue.
