Upgrading a very old SVN version

[Joanne Giammo]

Hello,

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.

Any guidance would be great!

Thank you,
Joanne

[Ryan Schmidt]

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.
Any guidance would be great!

1.x version are supposed to be compatible with one another. I would just try it. Dump your 1.3.2 repo, load it into a new 1.9.7 repo, see what happens.

[Joanne Giammo]

Hello Ryan,



Thank you for your quick reply.



1.x version are supposed to be compatible with one another. I would just try it. Dump your 1.3.2 repo, load it into a new 1.9.7 repo, see what happens.

We will try it out then.



Best Regards,

Joanne



-----Original Message-----
From: Ryan Schmidt [mailto:subversion-***@ryandesign.com]
Sent: Wednesday, December 13, 2017 11:43 AM
To: Joanne Giammo <***@kwi.com>
Cc: Subversion Users <***@subversion.apache.org>; Jonathan Rose <***@kwi.com>
Subject: Re: Upgrading a very old SVN version

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.
Any guidance would be great!

1.x version are supposed to be compatible with one another. I would just try it. Dump your 1.3.2 repo, load it into a new 1.9.7 repo, see what happens.

[Mark Phippard]

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.

2. When it is convenient, you can upgrade your repositories using a dump
and load (and you can do this one at a time)

- 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.


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.

[Nico Kadel-Garcia]

Post by Mark Phippard

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.

Post by Mark Phippard
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?

Post by Mark Phippard
- 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.

Post by Mark Phippard
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.

Post by Mark Phippard
--
Thanks
Mark Phippard
http://markphip.blogspot.com/

[Andreas Mohr]

Post by Nico Kadel-Garcia

Post by Mark Phippard
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.

Are we talking:
- full update, with certain suitable (last-minor stable) interim versions used?
- full update, going from earth to mars?

Possibly you're recommending "avoiding *both* variants of such a large jump,
if possible".


If this "problematic" sentiment holds, then interesting questions are:
- is an upgrade from very old versions generally supposed to be "doable"?
(i.e., should this use case be supported as best as can be?)
- if support ought to be best/improved, then how to analyze whether this
holds water? (in this particular case)
Would perhaps be good to go through such an upgrade for test purposes only,
then "play a bit" with the resulting test-only data
to possibly determine some issues.

HTH,

Andreas Mohr

[Johan Corveleyn]

Post by Andreas Mohr

Post by Nico Kadel-Garcia

Post by Mark Phippard
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.

- full update, with certain suitable (last-minor stable) interim versions used?
- full update, going from earth to mars?
Possibly you're recommending "avoiding *both* variants of such a large jump,
if possible".
- is an upgrade from very old versions generally supposed to be "doable"?
(i.e., should this use case be supported as best as can be?)
- if support ought to be best/improved, then how to analyze whether this
holds water? (in this particular case)
Would perhaps be good to go through such an upgrade for test purposes only,
then "play a bit" with the resulting test-only data
to possibly determine some issues.

I want to state clearly here that such an upgrade should work, and is
definitely supported. In gerenal, Subversion has very good
compatiblity and upgradeability guarantees. I'd expect no trouble,
even going from 1.0 to 1.9, but maybe that's just me ...

Of course, no software is free of bugs, so a good sysadmin is always
cautious when fiddling with important data such as the version control
backend (i.e. make a backup, or work on a copy of the original). But
I've never seen 'svnadmin upgrade' corrupt an svn database (note:
'svnadmin upgrade' does not rewrite the entire database, it only
adjusts the format so your new server binaries can start using new
features for newly created revisions).

Dumping and loading to rewrite your backend database into the latest
format is a bit more work, and there are a couple of hairy parts. But
those are quite well known (most notably, the fact that from SVN 1.6
onwards the backend enforced LF line-termination for properties,
without offering an option to normalize them with 'svnadmin load' --
OTOH svnsync has that option). I suggest going though the dump+load
faq entry [1] when you want to go that way (which also points to a
specific faq entry about the LF-error [2]).

Relatedly: soon SVN 1.10 will be released (the release train has
started for an RC1), which adds a --normalize-props option to
'svnadmin load' [3]. That should make this much easier.

[1] http://subversion.apache.org/faq.html#dumpload

[2] http://subversion.apache.org/faq.html#fix-nonLF-log

[3] http://svn.apache.org/viewvc?view=revision&revision=1807836