upgrade

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!)

Breaking Changes between .NET 1.1 and 2.0

Matt Simner .NET Framework, C#, Visual Studio ,

I spotted an old post from Brad Abrams on breaking changes for .NET 1.1 apps recompiled with 2.0.  The links had moved but are still relevant…


http://msdn2.microsoft.com/en-au/netframework/Aa570326.aspx


My own observations from converting projects are a little higher level in that I’m also interested in what effort you’re liable for when converting, and also things to watch out for if (like me) you’re having to persist a ‘shared’ code base of 1.1 and 2.0 core libraries (temporarily) while you migrate all your client apps.


ASP.NET Projects.  This includes Web Service projects.  You’ll find that you’ll probably have to reconstruct these projects based on the content files and you’ll also need to make a decision on the model you’re going to use for debugging – i.e. whether to use the new debugging host (removing IIS from the debugging equation) and whether to use a dynamic or static port.  Steer clear of the ‘Web Site’ project too as this could leave you confused for hours wondering why you can’t debug anything – look for the ASP.NET projects.  More info on the ASP.NET side can be found from Peter Laudati’s post.  Microsoft also have an article covering conversion of ASP.NET projects


DataSets.  These have changed in that a ‘designer’ file is now the main source file (apart from the .xsd).  If you’re sharing DataSets across 1.1 and 2.0 projects just share the .xsd file otherwise you’ll be asking for trouble as the other generated files are incompatible.  Any structural changes to a DataSet in one project (say .NET 1.1) will not be reflected in the corresponding 2.0 project.  You’ll need to check out the XSD in both places (assuming you’re using VSS) and build both in order to avoid breaking one of the projects.


Windows Forms.  I’ve had a recent experience where the InitializeComponent() method in a form (edited with VS 2005) places calls that aren’t compatible with .NET 1.1.  The code compiles (as below) but ‘exception thrown by target of an invocation’ gets thrown on the following line…


((System.ComponentModel.ISupportInitialize)(this.validatingProgress)).BeginInit();


This is because the control (a PictureBox in this case) doesn’t implement ISupportInitialize in .NET 1.1 but does in 2.0.  The equivalent in 1.1 is SuspendLayout()


This would just be one example of something that’s syntactically correct, but could fail at runtime.