subversion

ASPNETCOMPILER The Target Directory could not be deleted. Please delete it manually or choose a different target – SubVersion

Matt Simner Setup and Deployment, SubVersion, Visual Studio, Web

I’d added some projects to SubVersion today and later on added a CruiseControl.NET build.  I then started getting build failures due to the following:

ASPNETCOMPILER The Target Directory could not be deleted. Please delete it manually, or choose a different target

After a bit of looking around with the SysInternals Process Monitor I couldn’t find anything weird (e.g access denied due to someone locking the folder) and then saw that my output folder from the project (ASP.NET Web Deployment Project) was under SubVersion control (below)

Whoops! – after a swift delete of the folder (also in SubVersion) normality was resumed.  That’s another good reason not to put binaries into source control!

How to extract only changed files from SubVersion for partial deployment using TortoiseSVN

Matt Simner SubVersion , ,

I was really surprised how long it took me to find out how to do this – as it’s quite a simple operation, but if your deployment folder structure matches your SVN repository (e.g. classic ASP site, PHP etc) and you want to do a partial deployment of only files changed in a particular revision (or revisions) then here’s how to get the files (complete with folder structure) using TortoiseSVN:



  1. First you need to work out how you’re going to identify your revision range.  There’s a number of ways to go about this:


    1. Version comments are your friend

    2. You could just note the revision number when you commit.

    3. You could use tags to help identify the range.  I use CruiseControl.NET and so all ‘builds’ are automatically tagged.  If you always release from tags then you can just ‘show log’ on the tag and see the max revision number. 

    4. You could just use a date range.

  2. Once you’ve decided ‘how’ you’re going to identify the revisions (it may be as simple as the ‘last commit’) then either through your working copy, or from Repo Browser ‘show log’ on the root of your ‘deployment’ folder structure.  The files you’re interested in may be within a ‘code’ or ‘source’ folder or similar so you only want to get the files you want to deploy. 

  3. Select the revision/s based on the method you’re using (step 1) and do ‘Compare revisions’.  If you’re just looking at one revision then do ‘Compare with previous revision’.

  4. Review the list of files and select all (assuming the list looks correct) then right-click and ‘Export selection to…’

  5. The file structure will be created at the folder you specify, and you can then zip or do whatever you normally do to deploy.

If you only want the list of files then you can choose ‘Save list of selected files to…’ (text file).


This is all cool and simple, but it’s still quite a manual process.  If you’re certain of the revisions or you automatically keep track of the last deployment revision then it would probably make sense to automate this further with something like NAnt (which is what I’ll attempt to eventually get round to). 


This process also doesn’t cater for deletions (as such), so special care needs to be taken when reviewing the list of files (the action column shows the nature of the changes).

Upgrading SubVersion Server and Repositories to 1.5

Matt Simner SubVersion , ,

After upgrading TortoiseSVN and AnkhSVN to SubVersion 1.5, I set about upgrading the server this morning.  The main reason for this is that I wanted to merge a branch back into the trunk using the integrated merge option, and this simply doesn’t work with a 1.4x server and repository.  Everything needs to be 1.5 for that to work. 


We’re currently on 1.4.5 ish, from a previous 1-click Windows/Apache setup with some mods for groups authentication. 


I just downloaded the 1.50 server Windows binary and it actually now does a nice thing of asking whether you want to use SvnServe or Apache. 


I had some issues originally running Apache 2.2 with 1.4, and ended up with Apache 2.0.x but gave the new 1.5 install a go.  The following is how I upgraded my install from 1.4x using the same httpd.conf settings from the previous installation (link above).


Upgrading the Server



  1. Stop existing services (Apache etc)

  2. Back up your httpd.conf (my original install was apache 2.0 and went into a different folder) – but you’ll need the settings in any case

  3. Back up mod_auth_sspi.so from your existing Apache installation (/modules folder).  If you were using Apache 2.0 then don’t bother ‘cos it won’t work with 2.2.

  4. NOTE: If you want to upgrade your repository (required to use new 1.5 merging functionality) you need to first dump out the existing repository using the ‘old’ installation


    1. Backup the existing repository

    2. Run svnadmin /repos/path > dumpfile.txt

    3. You do the rest once you’ve upgraded the server

  5. Install 1.50 server (choosing Apache and whatever port / repository location you previously had.  You’ll replace the repository location later, but make sure your port’s right to save confusion and updates to httpd.conf).

  6. Edit the new httpd.conf replacing all ‘<Location>‘ sections at the bottom with that from your saved config.

  7. Paste the following line at the bottom of the LoadModule section
    LoadModule sspi_auth_module modules/mod_auth_sspi.so

  8. Copy an Apache 2.2-compatible mod_auth_sspi.so into the /modules folder.  As noted above if you take mod_auth_sspi.so that was compiled against Apache 2.0 you’ll get a message along the lines of:
     
    httpd: Syntax error on line 117 of C:/Program Files/CollabNet Subversion Server/httpd/conf/httpd.conf: API module structure ‘sspi_auth_module’ in file C:/Program Files/CollabNet Subversion Server/httpd/modules/mod_auth_sspi.so is garbled – expected signature 41503232 but saw 41503230 – perhaps this is not an Apache module DSO, or was compiled for a different Apache version?
     
    If you go to the home of mod_auth_sspi you’ll only find a module compiled against 2.0 so after hunting around a bit I found a copy compiled against 2.2.  Just copy the .so file into your modules folder)

  9. Start her up, and hopefully hey presto, you’ll have 1.50 server.  You can verify this easily by loading up the repository url in your browser and the footer should say something like… Powered by Subversion version 1.5.0 (r31699).

Upgrading the repository



  1. With the new version (1.5) binaries run:


    1. svnadmin create /temp/repos/path

    2. svnadmin load /temp/repos/path < dumpfile.txt

  2. Swap the old and new repository folders (useful to keep the backup)

  3. You’re all up to date.

Upgrading TortoiseSVN, Subversion 1.5 and AnkhSVN.

Matt Simner SubVersion, Visual Studio , , , ,

I thought I’d upgrade to v1.5 of TortoiseSVN this morning (leaving the server on V1.4.x) – of course completely forgetting that I use AnkhSVN in Visual Studio. 


New versions of TortoiseSVN and Subversion tend to upgrade the format for Working Copies.  This means AnkhSVN (1.02) was no longer compatible with my ‘new’ Working Copy and I got the following error…


This client is too old to work with Working copy ‘xxx’. Please get a newer Subversion client.


Thankfully AnkhSVN 2.0 is on the way and I downloaded a nightly build (2.0.4523.91) and installed (without uninstalling 1.0.2).  I usually do this to ‘test’ whether people write good installers.  Most people do the right thing with AutoUpgrade and 1.0.2 dutifully disappeared.


I loaded up Visual Studio with the same solution and – ‘Where’s my AnkhSVN menus gone?’.  As V2.0 is not even Alpha yet there’s not much in the way of obvious help on the Collabnet site.  The community area may have more, but I luckily didn’t need it.


I noticed in the application folder that there’s now an Ankh.Scc.dll.  Well blow me if they haven’t gone and made it a ‘standard’ Visual Studio SCC Provider!  Tools –> Options –> Source Control –> Plug-in Selection.  There it is.


Once you’ve got over that, then you might find a few little errors here and there, but the main difference is that instead of an ANKH menu on Tools and in the Solution Explorer context menu – you get a Subversion context menu. 


I’m liking it so far.  I think it’s probably stable enough to put your faith in and make the jump to SVN 1.5.


Update (08/07/2008) 
I submitted a bug report yesterday on an error I encountered (from the nice ‘send error details’ link) and got a reply saying ‘fixed in latest build’ the next day.  This bodes well!!!  Reasons to pay money for VisualSVN now disappearing fast…


Update (23/07/2008)


AnkhSVN v2.0 now officially out (that was a quick alpha/beta phase!)

Setting up SubVersion with Apache and Windows Group authentication

Matt Simner Development Process, SubVersion , , , ,

I found many links tell ing me how to do ‘most’ of this, but like lots of others, just couldn’t put together all the pieces.


My requirements were:



  1. Set up SubVersion to run with a remote repository (on a network drive that’s backed up)
  2. Run with Windows Authentication for all clients (tortoise, browser etc) and hook into the domain
  3. limit access to Windows Groups (not specific users) – to allow a single change to control everything (adding a user to a group that has access to the network resource).

Fact #1.  SubVersion only supports Windows Authentication through Apache.  There may be some hoops you can jump through to get that going with svnserve, but don’t go there.


Fact #2.  SubVersion does not support any Windows AD ‘group’ authentication through its config files, and so you have to do this through Apache.  It supports ‘custom’ groups that you can add domain users to.


The process.


Right, we now know you need to install SubVersion, Apache, and some other bits and pieces to allow Windows Authentication.


1. Install the main components (Follow all instructions on Trumpi’s blog).  This will set up SubVersion, Apache and the necessary modules to do Windows Authentication.


2. Change the ‘Location’ section at the bottom of the Apache httpd.conf to reflect your setup:  I’ve left in some commented lines to show some of the alternatives:


<Location /svn>
DAV svn
#SVNParentPath d:\LocalApp
#SVNPath D:\LocalApp\SVN
SVNPath //myserver/myshare$/SVN #NOTE the // rather than \\ in the UNC path name – you don’t have to use a mapped drive!!!


#User Authentication Policy
AuthName “Subversion”
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
SSPIDomain mydomain
SSPIOfferBasic On #Essential for TortoiseSVN to access the repository as it doesn’t support Windows integrated authentication
SSPIUsernameCase lower #allows you to type your username in lower case
SSPIOmitDomain On #allows you to just type your username without the domain\ qualifier


# our access control policy enforced by mod_authz_svn
#AuthzSVNAccessFile “D:\LocalApp\SVN\svnaccess.conf” #you shouldn’t need this


#SSLRequireSSL #Look at http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-serversetup.html#tsvn-serversetup-apache-5 if you need it
#require valid-user #User this line if you don’t need to limit to a group – i.e. any domain user
require group mydomain\mydomaingroup #here’s the magic for your group authorisation.  This limits access to the virtual directory
</Location>


3. Run the Apache2 service as a ‘generic’ domain user that is in your windows group (above).  This should also be part of the local administrators group on the web server (you can probably tweak this I was a bit lazy).  Access to the repository is then through the Apache user’s credentials, and each user will simply be authorised based on their group membership at the Apache level.