On 8/3/2017 1:10 PM, Baker, Randy (US) (Contractor) wrote:
Thank you for the speedy reply, and Yes, on purpose. I didn't think the list
could benefit from the language in my last email. So, if I may more thoroughly
explain : I'm a new hire here at this firm, tasked with upgrading the
Subversion server from RHEL 5x to 7x. That was done successfully, but a user
suggested I also upgrade the repos as well to benefit from the new server's
features. The current server (from which I ran 'svnadmin upgrade') is 1.6.11.
At the time, it was the only management server connected to NetApp (repos).
Now, when users attempt any svn work, they get the error I reported in the
ticket. So, now that I've added the new Subversion server (running 1.9.4) as a
management server to NetApp, what should be my next move?
Should I want to just do 'svnadmin upgrade <repo>' from the new server, or do
I need to dump and load the repos first? I have 200 repos, all production, so I'm
sure you understand the need for accuracy here. Apologies for being such a newbie
with this, but I'm being as cautious and informed as necessary. Thank you.
-----Original Message-----
From: Stefan Sperling [mailto:s...@elego.de]
Sent: Thursday, August 03, 2017 6:56 AM
To: Baker, Randy (US) (Contractor) <randy.ba...@baesystems.com>
Subject: Re: help with repo upgrade?
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.
On Thu, Aug 03, 2017 at 10:22:57AM +0000, Baker, Randy (US) (Contractor) wrote:
You're the second person to tell me this. I am not using 1.7. I'm using 1.9.4.
What exactly is it, in that article (which I've perused several times, by the
way), that I'm supposed to find that benefits my situation? Give me the
technical solution from that article that helps my scenario.
You forget to the Cc the list. Was this on purpose?
I think this discussion should stay on the public list to benefit people
reading the archives.
It does not matter which version you are using today.
What matters is the version which this reposiotry was created with.
It seems the repository in question was created with an 1.7.0 alpha release.
This should not have happened in a production setup. It may have been a mistake
or an experiment not meant to survive this long.
This repository can only be salvaged by installing that old alpha release and
dumping the repository with that release. This dump file can then be used with
1.9. This is what the link provided is supposed to explain.
Perhaps it did not explain clearly enough. Which part was unclear to you?
We can probbably improve the description if you explain where the existing text
lost you.
As stsp stated you first need to get grip of a 1.7.0-alpha build which
you can run against your repository. Given that s/o created the
repository with such an alpha version I'd guess that somewhere in your
company some backup of such a version should lie around somewhere. I'm
not aware of any publicly available binaries of such a version,
unfortunately. Worst case, you'll have to build such version from the
old source code (or s/o on this list can help out with that).
You then need to do an svnadmin dump with that particular alpha version
and the repository in question. When you got the dump, you'll setup a
fresh repository, set the UUID of the new repository to the old one and
do an svnadmin load with the 1.9.4 version of the previously stored dump
file into the new repository.
--
Regards,
Stefan Hett
