Updating Subversion's (SVN's) Repository Version

Sometimes it's necessary to manually upgrade Subversion's repository after upgrading Subversion (SVN) itself, such as to take advantage of a new feature. For example, I recently upgraded Subversion from 1.4 to 1.5, but did not upgrade my repository. This worked fine until I (inadvertently) tried to use a 1.5 feature. Using TortoiseSVN, I tried to merge a branch into the trunk using the 1.5 "merge tracking" feature, but because of the older repository version, I got an error something like "Error: Retrieval of mergeinfo unsupported by 'http://svnserver/myrepo'". Following are the steps I used to upgrade my repository.

• Check the Subversion server software version:
  • Logon to the computer on which the repository server software is running. From the command line, execute svnadmin --version to get the server software version.
  • Execute svn --version to check the client software.
• The server software version may be different from the repository version. To check the actual repository (layout) version number:
  • Navigate to <repository_dir>/db and open the file format. For SVN 1.5 compatibility, it should read something like:

      3
      layout shared 1000
    

    The key number here is 3. For SVN 1.4, this number is 2 and for SVN 1.6, 4.

• To upgrade the repository, the server command svnadmin upgrade <repos_dir> is often sufficient (as is the case going from SVN 1.4 to 1.5). Here's the help documentation for this command:

    Upgrade the repository located at REPOS_PATH to the latest supported
    schema version.
  
    This functionality is provided as a convenience for repository
    administrators who wish to make use of new Subversion functionality
    without having to undertake a potentially costly full repository dump
    and load operation.  As such, the upgrade performs only the minimum
    amount of work needed to accomplish this while still maintaining the
    integrity of the repository.  It does not guarantee the most optimized
    repository state as a dump and subsequent load would.
  
  

• Depending on which user did the update, it might be necessary to update the owner of the repository files. On Ubuntu Linux I had to issue the command sudo chmod -R www-data myrepo to change the owner of files from root back to www-data (the Apache user). Otherwise, trying to commit (remotely) to the repository will result in an error something like Can't open file '/path/to/repo/db/txn-current-lock': Permission denied

  Here's what others recommend:

  # chown -R www-data:www-data /var/svn/*
  # chmod -R 770 /var/svn/*
  
  assume that /var/svn/ is where are all your repositories
  

  (from svnform) and:

  $ sudo chown -R www-data:subversion myproject
  $ sudo chmod -R g+rws myproject
  

  (from ubuntu help).

The "LdrpWalkImportDescriptor() failed to probe XXX.dll for its manifest, ntstatus 0xc0150002" Error and Manifiests

I got this error the other day:

error: LDR: LdrpWalkImportDescriptor() failed to probe QtCored4.dll for its manifest, ntstatus 0xc0150002

I did some googling, and here's what I found out:

• The error may be a red herring, it's really a SideBySide DLL error. Look in the Event Viewer (see Control Panel, Administrative Tools) for the real error [Mombu, MSDN Social]. It turned out the Microsoft.VC80.DebugCRT DLL could not be found.
• Usually occurs because of missing DLLs, or DLLs with the incorrect version number (as specified in the DLL's manifest) on the deployment machine.
• Solutions:


• Recompile the offending DLL(s) [Nabble, Bytes]
• Recompile the offending DLL(s), but make sure the DLL project is configured to embed the manifest in the DLL. Have a look at the "dependentAssembly" tag in the generated YourDLLName.intermediate.manifest file. It must be the same as the "dependentAssembly" version in the manifest file generated for your EXE project. Make sure the same service packs are installed (i.e. same msvc) on the machine that built the DLL and the one that built the EXE [Trolltech Lists]
• Recompile the offending DLL(s), or download and install MSVC Redist SP1 [OpenCV Wiki]
  


• FAQ on manifests [CodeGuru]

Here's what worked for me: I checked the manifest file in the DLL that caused the error -- QtCore4d.dll in this example -- and noticed it required the Microsoft.VC80.DebugCRT DLL of a certain version. A colleague of mine compiled the DLL, so I had easy access to the manifest since an "intermediate" copy is stored in the DLL project's build directory. If that wasn't the case, I could use mt.exe from Microsoft to extract it from the DLL. I then inspected the manifest generated by Visual Studio when I compiled my EXE project. It turned out my EXE manifest required a version of the Microsoft.VC80.DebugCRT DLL that was older than that required by the QtCore4d.dll DLL, which means my machine had older DLLs than that required by QtCored4.dll. I simply applied a few Microsoft Visual Studio updates, recompiled my EXE project (not the DLL project), and the newly generated manifest showed the dependent DLL (Microsoft.VC80.DebugCRT) version to be the same as that in the QtCored4.dll manifest. Everything worked fine afterwards.