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
format 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
Received on 2008-02-14 20:29:02 CET