gui wrote:
> Hi All
>
> I have a svn repository from an old server which has been scrapped.
> When I copied the svn repository onto a new server running the latest
> subversion
> and tried to check it out, I got error message saying 'repository not
> found'.
>
> The svn repository has a 'format' file in the db directory which
> contains the number '1'.
> I guess this is the repository format 1. But there is no 'format'
> file in the root
> level of the repository.
>
> I tried installed subversion versions 0.32.1, 0.28.2 and 0.19.1 but
> all did not work.
> I think it is because the repository is using FSFS and 0.32.1, 0.28.2
> and 0.19.1 still do not
> have FSFS (only db).
> Only 0.19.1 uses format 1 - but it does not use FSFS.
> So it is strange that the repository is using FSFS and having format 1
> (in the db directory
> and not in top level directory).
>
> README.txt conf dav db
> hooks locks
>
> inside db/
> __db.001 __db.002 __db.003 __db.004
> __db.005 current format fs-type
> revprops revs transactions
>
>
> fs-type is fsfs.
>
> This is really strange. Has the repository been corrupted?
>
> Thank you.
> Gui
>
>
>
>
> On Friday 08 December 2006 18:09, gui wrote:
> > > Hi All
> > >
> > > I have two SVN repositories which are in format 1.
> > > The subversion server I have now is 1.4_01 - using format 3?
> > >
> > > When I try to checkout the two format 1 SVN repositories,
> > > I get the "No repository found in svn://..." error.
> > >
> > > What should I do to upgrade the two SVN repositories to
> > > format 3 so that I can checkout them?
> You have to dump the repositories, create new ones and import the
> dumpfile to
> them.
>
> Looks about this way:
>
> cd <repository parent dir>
> svnadmin dump <repository> --deltas > dumpfile
> mv <repository> <repository>.old
> svnadmin create <repository>
> svnadmin load <repository> < dumpfile
> rm dumpfile
>
> or using a pipe, so you don't have to save the dumpfile to disk
>
> cd <repository parent dir>
> mv <repository> <repository>.old
> svnadmin create <repository>
> svnadmin dump <repository>.old --deltas | svnadmin load <repository>
>
> Here you maybe don't need the '--deltas' option, it only saves space
> in the
> dumpfile. I'm not sure if it's here faster with or without it.
>
> Best,
> Martin
>
> -------------
>
>
> HOW-TO: svn repository upgrade procedure
> =========================================
> $LastChangedDate$
>
>
> WHO IS AFFECTED:
> ---------------
>
> Anyone upgrading between versions of subversion that have different
> repository schemas. Schema versions are as follows:
>
> SUBVERSION VERSION NUMBER SCHEMA VERSION
> ------------------------- --------------
> Up to and including 0.27 1
> 0.28 - 0.33.1 2
> 0.34 - 1.3 3
> (no released version used this) 4
> 1.4 - 5
>
> If necessary you can see which schema version your repository is
> currently using by looking at the format file in the repository.
>
> It should be noted that these changes are extremely rare. Now that
> subversion has reached 1.0.0 our compatibility guarantees require
> forward and backward compatible repository formats for all patch
> releases and backward compatible for minor releases. So until
> 2.0.0 comes out there will be no change that should require a
> dump for upgrading to newer versions.
>
> While Subversion does create version 5 repositories by default as of
> version 1.4, it still supports reading and writing version 3
> repositories for backwards compatibility. Additionally, a pre-1.3
> client can communicate with a 1.4+ server accessing a version 5
> repository.
>
>
> PROBLEM:
> -------
>
> At times during the development of subversion it has and will be
> necessary to change the underlying database schema for subversion
> repositories (libsvn_fs). 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
>
> So if you're seeing an error like these you will need to upgrade or
> downgrade your repository version.
>
>
> HOW TO UPGRADE/DOWNGRADE YOUR REPOSITORY:
> ----------------------------------------
>
> 1. Use an 'svnadmin' binary from a release with the same schema version
> as your repository to create a dumpfile of your repository:
>
> $ mv myrepos old-repos
> $ svnadmin dump old-repos > dumpfile
>
> 2. Use an 'svnadmin' binary from a release with the same schema version
> as you want your repository to have 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
>
> (If you are running at least version 1.4 and would like to make a
> format 3 repository, pass the --pre-1.4-compatible flag to
> "svnadmin create".)
>
> 3. [OPTIONAL] Loading a dumpfile is both time- and disk-consuming,
> as it replays every commit. If your new repository is a BDB
> respository, then 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
>
> Note: If you're using BerkeleyDB 4.2 or newer this will be done
> automatically for you, unless you've configured the repository
> not to behave this way.
>
> 4. Don't forget to copy over any hook scripts (and DB_CONFIG for BDB
> repositories, 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 was still pre-1.0 when the changes that required schema
> versions 2 and 3 were made, and thus constantly improving. These
> changes were planned, and took a long time to complete. They fix both
> efficiency and correctness problems in the database code.
>
> The change made in schema version 5 is just that the "db" part of the
> repository now has its own independent schema version file; this was
> used in Subversion 1.4 to support a new version of FSFS which
> compresses some of its data for better space usage. However, we will
> continue to support schema version 3 throughout all of Subversion 1.x.
>
> In the future it may be necessary to make changes to support new
> features. But we will do so in a manner that is consistent with our
> compatibility guarantees.
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-02-14 20:29:39 CET