Issue #519 resolved

Default SVN repository format setting creates incompatible repositories

FunkyCandyman
created an issue

SVN repositories created with the option "Mit Version 1.7 kompatibel" are neither compatible with svn 1.7 nor svn 1.8 command line clients.

When creating repositories with this preset they are created with the 1.7alpha format (as indicated by db/format: '5'), which is neither supported by the final svn 1.7 nor svn 1.8 (https://subversion.apache.org/docs/release-notes/1.7.html#revprop-packing). This means repositories created with this format can not be "svn upgrade"d or even dumped with any non-1.7alpha-client, which is a pretty serious issue, I assume, as it would probably render all repositories created with this format unusable when you update svnkit in scm-manager.

Here are the outputs of some commands I issued on a scm-manager 1.7 repository with 1.7 and 1.8 clients:

# svnadmin --version
svnadmin, version 1.7.14 (r1542130)
   compiled Nov 19 2013, 11:00:22

Copyright (C) 2013 The Apache Software Foundation.
This software consists of contributions made by many people; see the NOTICE
file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository back-end (FS) modules are available:

* fs_base : Module for working with a Berkeley DB repository.
* fs_fs : Module for working with a plain file (FSFS) repository.

# cat testrepo01/db/format
5
layout sharded 1000

# svnadmin upgrade testrepo01
Repository lock acquired.
Please wait; upgrading the repository may take some time...
svnadmin: E160043: Found format '5', only created by unreleased dev builds; see http://subversion.apache.org/docs/release-notes/1.7#revprop-packing

# svnadmin upgrade testrepo01
Repository lock acquired.
Please wait; upgrading the repository may take some time...
svnadmin: E160043: Found format '5', only created by unreleased dev builds; see http://subversion.apache.org/docs/release-notes/1.7#revprop-packing

# svnadmin dump testrepo01 > test.dmp
svnadmin: E160043: Found format '5', only created by unreleased dev builds; see http://subversion.apache.org/docs/release-notes/1.7#revprop-packing

# cat test.dmp
*empty*



# svnadmin --version
svnadmin, version 1.8.5 (r1542147)
   compiled Nov 19 2013, 15:28:00 on x86_64-unknown-linux-gnu

Copyright (C) 2013 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository back-end (FS) modules are available:

* fs_fs : Module for working with a plain file (FSFS) repository.
* fs_base : Module for working with a Berkeley DB repository.

# cat testrepo02/db/format
5
layout sharded 1000

# svnadmin upgrade testrepo01
Repository lock acquired.
Please wait; upgrading the repository may take some time...
svnadmin: E160043: Found format '5', only created by unreleased dev builds; see http://subversion.apache.org/docs/release-notes/1.7#revprop-packing

# svnadmin upgrade testrepo01
Repository lock acquired.
Please wait; upgrading the repository may take some time...
svnadmin: E160043: Found format '5', only created by unreleased dev builds; see http://subversion.apache.org/docs/release-notes/1.7#revprop-packing

# svnadmin dump testrepo01 > test.dmp
svnadmin: E160043: Found format '5', only created by unreleased dev builds; see http://subversion.apache.org/docs/release-notes/1.7#revprop-packing

# cat test.dmp
*empty*

I don't use this format at the moment but I can imagine a lot of people do. What should they do with their repositories?

Comments (19)

  1. Sebastian Sdorra repo owner

    I think the only way to fix this, is to dump the repository with the old version and import the dump with a newer version of svnkit. This could be very difficult. I will try to fix this.

  2. Sebastian Sdorra repo owner

    Ok, i was able to solve the first part of the problem. I've created a small program which is able to convert a subversion db 5 format to a db 6 format.

    Source:

    Binary:

    Usage download the binary and start it with the following command:

    java -jar scm-fixsvndb5-cli...jar brokenrepo targetrepo
    

    Next steps to fix the whole problem:

    • update scm-fixsvndb5 to find broken repositories in scm home
    • update sonia.svnkit to latest version of org.tmatesoft.svnkit
    • modify scm-manager to use the new created version sonia.svnkit
    • mark broken repositories in new version of scm-manager and provide a tutorial for the fix
  3. Sebastian Sdorra repo owner

    Here is a snapshot release of the upcoming version 1.36 of SCM-Manager which ships version 1.8.3-scm1 of svnkit (which creates non broken subversion repositories). This version marks subversion repositories with db format 5 as unhealthy and points the user to this wiki page.

    Snapshot of 1.36:

    Could you please test the version above?

  4. FunkyCandyman reporter

    I tested with the file from here and found the following problems:

    1 The given url to the wiki page is not correct is: https://bitbucket.org/sdorra/scm-manager/wiki/healtchecks/svn-incompatible-dbformat

    should be: https://bitbucket.org/sdorra/scm-manager/wiki/Incompatible%20subversion%20db%20format

    2 A click on the "rerun health checks" link sometimes triggers an exception that causes the server to return a 500 status code and thus bringing up the following error message in the repository listing: "Could not load items. Server returned status: 500". The corresponding Tomcat log will be attached to this ticket. The error occurs when the GUI tries to fetch the repository listing (/api/rest/repositories.json) - the POST request to the check action went successful and returned a status code 200.

    3 I'm running a Tomcat (7.0.47) application server, which doesn't shut down in time with your posted version when issuing the shutdown command (via the tomcat-management scripts in {TOMCATROOT}/bin) if the server was started a few (maybe up to 5) minutes before. That causes another error message to be written to catalina.out - I will attach a log excerpt of that, too.

  5. FunkyCandyman reporter

    I updated Tomcat (again - I thought, I did that a few days ago :S) to 7.0.50. Changelog said they changed/fixed the behaviour when shutting down and searching for memory leaks in 7.0.48 and it seems to be working now.

    As you added svnkit 1.8.3, will there be support for SVN 1.8 repositories in the near future as well?

  6. FunkyCandyman reporter

    I did some testing with the last version you gave me and I found an error when archiving repositories or getting them back out of the archive. It seems to be caused by the health checker mechanism you implemented. The error occurs with Subversion and Git repositories - I did no testing with Mercurial as it isn't installed, yet.

    The repositories won't get (de)archived with the message: "Das Archivieren des Repositories ist fehlgeschlagen."

  7. Log in to comment