
HOW-TO:  svn repository upgrade procedure
=========================================
 $LastChangedDate: 2003-08-29 09:34:05 -0500 (Fri, 29 Aug 2003) $


WHO IS AFFECTED:
---------------

Anyone upgrading to svn 0.28 (or later) who has a repository created
with an earlier release.


PROBLEM:
-------

In revision (6752, /trunk) [August 16, 2003], the underlying database
schema for subversion repositories (libsvn_fs) was changed.  Thus, if
a 'new' libsvn_fs library tries to access an 'old' repository, you'll
see an error like:

   Expected version '2' of repository; found version '1'

   or

   svn: No repository found in '...URL...'

Or if you use an 'old' libsvn_fs library to access a 'new' repository,
you might see an error like:
  
   Expected version '1' of repository; found version '2'

   or

   svn: Malformed skeleton data
   svn: Malformed node-revision skeleton

This schema change became public in svn 0.28.  So if you're upgrading
a server to svn 0.28 or later, you need to convert your repository to
the new schema.


HOW TO UPGRADE YOUR REPOSITORY:
------------------------------

  1. Use an 'svnadmin' binary from release 0.27 (or older) to create a
     dumpfile of your repository:

        $ mv myrepos old-repos
        $ svnadmin dump old-repos > dumpfile

  2. Use an 'svnadmin' binary from release 0.28 (or newer) to load the
     dumpfile into a new repository:

        $ svnadmin create myrepos
        $ svnadmin load myrepos < dumpfile

     OR, if you're feeling saucy, you can do it all at once with a pipe:

        $ svnadmin-new create myrepos
        $ svnadmin-old dump old-repos | svnadmin-new load myrepos

  3. [OPTIONAL] Loading a dumpfile is both time- and disk-consuming,
     as it replays every commit.  After the load is complete, you may
     want to free up some disk space by removing unused BerkeleyDB
     logfiles:

        $ svnadmin list-unused-dblogs newrepos | xargs rm

  4. Don't forget to copy over any hook scripts (and DB_CONFIG, if you
     changed it) from the old to the new repository:

        $ cp old-repos/hooks/* repos/hooks/
        $ cp old-repos/db/DB_CONFIG repos/db/


WHY DID YOU CHANGE THE SCHEMA?
-----------------------------

Subversion is still pre-1.0, and thus constantly improving.  These
changes were planned long ago, and took a long time to complete.
They fix both efficiency and correctness problems in the database
code.

More tangible results of this change are:

  * 'svn log branch/foo.c' now shows the branch-creation as a real
    event in foo.c's history, even though foo.c itself was only
    *implicitly* copied when its parent got copied.

  * 'svn log -rX:Y' is doing less work.

  * Fixes bugs in 'svn log --strict'.

  * We have a new fs API for walking the history of a node using a
    cursor-like interface.

  * Internally, the mechanism for choosing copyids was broken.  (OK,
    that's not tangible, but a matter of correctness.)

