Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo


SVN and project upgrades

Dave Brondsema Chris Tsai Rich Bowen Cory Johns

After upgrading to the new SourceForge (Allura) your SVN URLs will change. This document attempts to answer some of the more common questions about this change.

Q: What do I need to do?

A: As the project admin, you have a choice of how you handle the change in your SVN URL.

If your repository is small, or if you have a fairly small number of developers, it’s probably easiest to have your developers delete their working copy and get a fresh checkout from the new URL. Give your developers sufficient warning of the upgrade that they can check in any outstanding changes that they have in their working copies.

However, if you have a large number of developers, or if your repository is large enough that checking it out again takes a long time, you’ll need to update the UUID on the new repository to match the old one. as of 2013-01-14, UUIDs are preserved for new upgrades. If you upgraded your project prior to 2013-01-14, please see an older revision of this page for instructions on updating the UUID.

After upgrade, everyone with a working copy of the repository needs to update their WC to point at the new location. Run the svn relocate command in the root of your working copy:

$ svn relocate https://svn.code.sf.net/p/PROJECT/code/

Verify what your new svn repository URL is on your project code page. For example, if you have several repository types, they may be named svn or git, rather than code.

Older versions will need to use switch instead:

$ svn switch --relocate OLD-REPO-URL https://svn.code.sf.net/p/PROJECT/code/

You can get the old repo URL from the info command:

$ svn info

Note that the URL paths need to match, that is, if your old URL ends in /trunk, the new one must as well, and vice-versa. If not, you may get the error:

svn: Can't find entry

If you get this, try adding or removing /trunk from the end of both URLs.

A: The URLs of your old repository - both the repository itself, and the ViewVC interface to that repository, will not change yet. We will keep them referencing the classic SVN repository, so you can verify that everything migrated over properly. In early 2013, we plan to redirect the ViewVC web pages over to the new code browser. We'll also be investigating how to do that for the repository itself.

Q: What if I continued to use the old repository after upgrade?

A: You have a few options for updating the new repository to catch up to the classic one.

  • This is the easiest, though if you have a very large repository, it may take considerable amount of time.

    • Go to Admin -> Tools, then where your SVN repo is listed, select "import repository"
    • On that page, enter your old repo URL:
  • This requires a bit more work, but can be a significant time savings if you have a very large repository:

    • Start a shell session
    • Use adminrepo to mount a copy of your old repository: adminrepo --checkout svn
    • Use svnadmin dump to make a dump of the changes, replacing UPPER:LOWER with the range of the missing revision numbers (eg. 123:135 ):
      $ svnadmin dump /svnroot/PROJECT -r LOWER:UPPER --incremental > /home/project-web/PROJECT/incremental_dump
    • Use svnadmin load to load the changes into your new repository:
      $ svnadmin load /home/svn/p/PROJECT/code < /home/project-web/PROJECT/incremental_dump
    • Then go to Admin -> Tools, and where your svn repo is listed, select "Refresh Repository" to update the code browser.
    • Once you confirm that everything looks good, remove the dump file, discard the adminrepo checkout, then shutdown and exit the shell session:
      $ rm /home/project-web/PROJECT/incremental_dump
      $ adminrepo --discard svn
      $ shutdown ; exit

Q: I really need to use the old repository, but it won't let me, what can I do?

A: Please log a support ticket for this, and we can set your classic repo to read/write again. This will only be temporary however, you will still need to make plans to migrate to the new repo when possible.