help with repo upgrade?

[Baker, Randy (US) (Contractor)]

Hello : I was tasked with upgrading Subversion server and repos. I have built a new server. Old server was at 1.6.11; new server 1.9.4. Clients report no issues accessing new Subversion 1.9.4 from various versions of client. However, upgrading the repo, I get the following :



svn: E160043: Found format '5', only created by unreleased dev builds



I need help understanding how the upgrading works, and, more specifically, how I can successfully get past this issue and successfully upgrade the repos.







Randy Baker
Linux Systems Admin, BAE (SoftWorld, Inc.)
W 781.262.4291

[Stefan Sperling]

Post by Baker, Randy (US) (Contractor)
svn: E160043: Found format '5', only created by unreleased dev builds
I need help understanding how the upgrading works, and, more specifically, how I can successfully get past this issue and successfully upgrade the repos.

See http://subversion.apache.org/docs/release-notes/1.7#revprop-packing

[Baker, Randy (US) (Contractor)]

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:***@elego.de]
Sent: Thursday, August 03, 2017 6:56 AM
To: Baker, Randy (US) (Contractor) <***@baesystems.com>
Subject: Re: help with repo upgrade?

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

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.

[Stefan Hett]

Post by Baker, Randy (US) (Contractor)
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-----
Sent: Thursday, August 03, 2017 6:56 AM
Subject: Re: help with repo upgrade?
*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

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.

[Stefan Sperling]

On Thu, Aug 03, 2017 at 11:10:07AM +0000, Baker, Randy (US) (Contractor)

Post by Baker, Randy (US) (Contractor)
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.

There must be a missing link in this story somewhere.

A 1.6.11 'svnadmin upgrade' would *not* create a format 5 repository.
It would create format 4.

Are you 100% sure that you (or someone else) didn't run 'svnadmin upgrade'
with a 1.7 alpha release accidentally? That's the only possible
explanation for the error you are seeing. At least I cannot think of
any other reason (apart from manual meddling with repository data, but
that's obviously not a supported use case either).

How many repositories are affected by this? All of them? Just one?