On Wed, Dec 13, 2017 at 2:27 PM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Wed, Dec 13, 2017 at 11:01 AM, Joanne Giammo <jgiammo_at_kwi.com> wrote:
>
>>
>> My company had been working with a very old version of SVN – 1.3.2 from
>> 2006
>>
>> They are planning to upgrade to the latest version – currently 1.9.7
>>
>>
>>
>> I realize that an upgrade from 1.3.2 to 1.9.7 is a serious jump.
>>
>> Are there any know issues doing an upgrade such as this?
>> Is this full upgrade recommended or should the upgrade be done in stages
>> until we reach 1.9.7?
>> We don’t want to lose the check-in history of all the files.
>
>
> Subversion has good compatibility so I recommend doing this in stages.
>
> 1. Upgrade your server to 1.9.7 but have it just serve the same repositories
> as before
>
> You do not have to upgrade your repositories and the server should work with
> them fine. This gives you time to make sure everything is OK with the new
> version and you have all of the right binaries and it is configured
> correctly etc.
Seriously, *do not* do this with your live service. It is possible to
really, really mess up your working repository with untested update
structures from such an old version. There have been numerous
structural changes since 1.3.x, especially EOL handlinng for comments.
Schedule downtime to avoid split brain, Do a full filesystem backup to
a host running Subversion 1.9.x, and test with *that* if you have to.
> 2. When it is convenient, you can upgrade your repositories using a dump
> and load (and you can do this one at a time)
Do you see any compelling reason not to do dump on one, obsolete and
load on another?
> - Subversion 1.5 introduced merge tracking and it required your repository
> to be upgrade to enable the feature. So even though you have installed
> 1.9.7, you will not be able to start using merge tracking until you upgrade
> the repository format
> - Many Subversion releases offer improvements in how the repository data is
> stored. Usually, it is just using less disk space but also sometimes it
> offers performance improvements just by how the data is stored
>
> Going through a dump/load process will allow you to upgrade to the latest
> version.
Amen.
> Step 1 is very safe and easy and you are unlikely to encounter problems.
> Step 2 is more of an unknown. There are various bugs that existed in older
> versions that allowed some data to be stored in repository in format that
> was in violation of what was intended. Newer versions of Subversion detect
> and enforce those rules better. If you have any of this data you might get
> errors when loading the repository to the new format. If you do, you can
> search the archives of this list to find answers on how to proceed.
Jumping that far between versions, I'd *expect* trouble. The
repository is basically a file-system based database. I'd urge *not*
updating that in place.
>
> --
> Thanks
>
> Mark Phippard
> http://markphip.blogspot.com/
Received on 2017-12-13 23:19:56 CET