Upgrade Subversion from 1.5 to 1.9

[Safarulla Meerasahib]

Hi,

 

We have recently taken over a production  application from other team, which uses the SVN 1.5.0 as one of the component. Now we have a requirement to upgrade this to latest version of the subversion.

While going through the Apache subversion link we have noticed that Subversion 1.9 can only upgrade working copies created with Subversion 1.6 and Subversion 1.7.

Is there any workaround to upgrade 1.5.0 to 1.9?

 

Thanks & Regards,

Safarulla M.

 

[Stefan Sperling]

Use 'svn checkout' to get new working copies after upgrading.
Note that working copies are only used by the Subversion client.

A 1.9 server is fully backwards compatible to repositories created
by any version of Subversion.

If you are unsure about the differences between working copies and
repositories, please read this page:
http://svnbook.red-bean.com/nightly/en/svn.basic.version-control-basics.html

[jbl...@icloud.com]

There is a difference between upgrading the repository and upgrading a working copy. As long as all the code has been committed to the repository, you can simply check out a new working copy using the new client and not be concerned.

Upgrading a repository is a not an issue either since the server is quite forward compatible. That said, if your old repository is based on BerkeleyDB you will need to ensure that the new version of SVN is also built to use BDB. Alternatively, you can perform "svnadmin dump" on the old repository and use "svnadmin load" on the new to transform your repository regardless of the storage method.

So, make sure you understand the difference between a repository and a working copy.

[Daniel Shahaf]

Stefan Sperling wrote on Mon, Mar 21, 2016 at 20:58:37 +0100:
> On Mon, Mar 21, 2016 at 10:33:49AM -0700, Safarulla Meerasahib wrote:
> > Hi,
> >
> >
> >
> > We have recently taken over a production application from other team, which uses the SVN 1.5.0 as one of the component. Now we have a requirement to upgrade this to latest version of the subversion.
> >
> > While going through the Apache subversion link we have noticed that Subversion 1.9 can only upgrade working copies created with Subversion 1.6 and Subversion 1.7.
> >
> > Is there any workaround to upgrade 1.5.0 to 1.9?
>
> Use 'svn checkout' to get new working copies after upgrading.
> Note that working copies are only used by the Subversion client.

For working copies, you can instead first install 1.6 or 1.7, upgrade
all working copies, then install 1.9 and upgrade them again.

There are still various restrictions, such as [1], so be sure to read
the release notes for all intermediate versions (1.6 through 1.9
inclusive).

Cheers,

Daniel

[1] http://subversion.apache.org/docs/release-notes/1.7#wc-upgrade

[Nico Kadel-Garcia]

On Mon, Mar 21, 2016 at 3:58 PM, Stefan Sperling <st...@elego.de> wrote:
> On Mon, Mar 21, 2016 at 10:33:49AM -0700, Safarulla Meerasahib wrote:
>> Hi,
>>
>>
>>
>> We have recently taken over a production application from other team, which uses the SVN 1.5.0 as one of the component. Now we have a requirement to upgrade this to latest version of the subversion.
>>
>> While going through the Apache subversion link we have noticed that Subversion 1.9 can only upgrade working copies created with Subversion 1.6 and Subversion 1.7.
>>
>> Is there any workaround to upgrade 1.5.0 to 1.9?
>
> Use 'svn checkout' to get new working copies after upgrading.
> Note that working copies are only used by the Subversion client.

It can be much safer to designate a second server with a fresh copy of
the new version of Subversion, Subverison 1.9 if available, to create
a slave of the original repository. This leave the original repository
usable until the final switchover It's especially if the repository
has gotten large, over time, with binary commits and many branches.

Then, when ready to switchover, make a good backup of the old system,
*LOCK IT* to prevent any further ocmmits, and switch services to the
new server. You should be able to activate a proxy or port forwarding
for the old service, if needed, so anyone who accidentally tries to
reach the old one actually gets the new one.

[Bert Huijben]

I’m not sure where you read that, but subversion can upgrade working copies all the way up from 1.0. (See our compatibility guarantee)

 

There is one exception: If a working copy operation was stopped halfway… in this case you need to run ‘svn cleanup’ with your older Subversion version (or 1.6.x) prior to upgrading to Subversion 1.7 or newer.

 

You would have seen an error at the end of the operation and/or explicitly cancelled the operation as a user in all cases where you need this.

 

                Bert

[Stefan Sperling]

On Tue, Mar 22, 2016 at 12:25:42AM -0400, Nico Kadel-Garcia wrote:
> Then, when ready to switchover, make a good backup of the old system,
> *LOCK IT* to prevent any further ocmmits, and switch services to the
> new server. You should be able to activate a proxy or port forwarding
> for the old service, if needed, so anyone who accidentally tries to
> reach the old one actually gets the new one.

If all deployed clients are >= 1.7, HTTP redirects from old server to the
new server will take of moving clients over to the new server automatically:
http://subversion.apache.org/docs/release-notes/1.7.html#http-redirects

This only matters if the URL has changed, of course. If you can switch the
server while keeping the URL intact, that's even better.

[Lorenz]

Bert Huijben wrote:

>I'm not sure where you read that, but subversion can upgrade working copies
>all the way up from 1.0. (See our compatibility guarantee)

perhapse here:
http://subversion.apache.org/docs/release-notes/1.9.html#wc-upgrade

>>Subversion 1.9 can only upgrade working copies created with
>>Subversion 1.6 and Subversion 1.7.

--

Lorenz

[Nico Kadel-Garcia]

On Tue, Mar 22, 2016 at 6:47 AM, Stefan Sperling <st...@elego.de> wrote:
> On Tue, Mar 22, 2016 at 12:25:42AM -0400, Nico Kadel-Garcia wrote:
>> Then, when ready to switchover, make a good backup of the old system,
>> *LOCK IT* to prevent any further ocmmits, and switch services to the
>> new server. You should be able to activate a proxy or port forwarding
>> for the old service, if needed, so anyone who accidentally tries to
>> reach the old one actually gets the new one.
>
> If all deployed clients are >= 1.7, HTTP redirects from old server to the
> new server will take of moving clients over to the new server automatically:
> http://subversion.apache.org/docs/release-notes/1.7.html#http-redirects

My big concern would be anyone continuing to write to the old server,
irrelevant of redirects. Local file based Subversion access, svn_ssh
access that hasn't been disabled, and dangling svnserve based services
also need to be either never made available, or forcibly blocked, to
prevent fascinating split-brain problems.

Redirects.... well, that relies on enough control of web servers based
access, possibly including DNS, to ensure a reliable redirect.

> This only matters if the URL has changed, of course. If you can switch the
> server while keeping the URL intact, that's even better.

Yeah, *locking* the old service becomes pretty critical. If one can
ensure that *no* write occur to the new server that didn't occur on
the old server first, before the switchover happens, it's invaluable
to help prevent split-brain problems.