0

I am going to be performing a server migration for our SVN repos hosted on Enterprise Linux 6.2 using SVN 1.6.9 over svnserve (svn://) and mod_dav_svn (http://). I will be using the svnbackup.pl (svnadmin dump) and svnrestore.pl scripts to make backups from one server, create the repos on the new server and restore to the new repos. I would like to install SVN 1.7.9 (latest stable) on the new server and wanted to know if anyone has experience with this, or if anyone has encountered any issues with restoring backups from a 1.6.9 repo to a 1.7.9 repo. Thanks in advance! Centos 6.4 on destination server.

  • Why are you migrating, exactly? The RHEL (or CentOS) package might have an old version number, that doesn't mean it has all the bugs of that version. Installing random stuff will break your setup. – vonbrand Apr 18 '13 at 20:31
  • I am moving to an entirely new server. The old server has the version from the repos, and I was considering downloading and installing the latest stable (1.7.9) from the web and installing it to the new server before migrating the repo data over. – user160910 Apr 18 '13 at 20:54
0

I did svn 1.5 to svn 1.6, so, this is what I did:

  1. I left the production running on svn 1.5 as is. My repos are in /opt/repos/svn/

  2. I installed svn 1.6 + https and relative modules on another host. The location of the repo is exactly the same, i.e. /opt/repos/svn.

  3. I svnhotcopy or svndump all repos to its own files and scp-ed over to /opt/repos/svn on the machine running svn 1.6. If no one is using svn, you can even rsync it. svnhotcopy is a great tool, it will create a copy of a repo while it is in use, to avoid any data corruption.

  4. Then I pointed my svn client to the new host, checked out repo I have access to. Updated some files, checked it in, I could view my files on https as we used cvsweb. This was my test that it works.

  5. For my maintenance, I had everyone exit out of svn, after hours, I removed all repos on the new host, rsync-ed repos from old host to the new host. Change DNS to point svn CNAME to the new host. The new host became my production host and the old host, I upgraded to 1.6 and is now my standby host.

Do not upgrade it without any backup. Backup all repos and upgrade it on another host. SVN is an important tool, you must have a standby host just in case your production goes down.

Good luck.

| improve this answer | |
  • Also, let me know if you have any questions. Plus, make sure the developers are onboard with it and they have upgraded their clients to use the new server. – Nikolas Sakic Apr 18 '13 at 20:46
  • I was curious about that. We mostly use Windows clients, TortoiseSVN. Does the client version need to match the server version of SVN? Will the working copies that are checked out from 1.6 be compatible/in-sync with the 1.7 backend? – user160910 Apr 18 '13 at 21:11
  • we had an issue with someone using Subversion 1.6 client with Subversion 1.5 server on Linux. What happened was that the guy using 1.6 client, when he checked out the code, everything was fine. When he checked code in using 1.6 client, everything worked for him. The developer who was using 1.5 subversion client, when he did svn update, at some point he got segmentation fault. The client died while trying to checkout the code. So, I upgraded his client to subversion 1.6. We don't have any windows client but I don't see any issues with someone using TortoiseSVN. – Nikolas Sakic Apr 19 '13 at 3:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy