Upgrading a very old SVN version

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

 

Reply | Threaded
Open this post in threaded view
|

Re: Upgrading a very old SVN version

Ryan Schmidt-8

On Dec 13, 2017, at 10:01, Joanne Giammo 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.
>  
> 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.


Reply | Threaded
Open this post in threaded view
|

RE: Upgrading a very old SVN version

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:[hidden email]]
Sent: Wednesday, December 13, 2017 11:43 AM
To: Joanne Giammo <[hidden email]>
Cc: Subversion Users <[hidden email]>; Jonathan Rose <[hidden email]>
Subject: Re: Upgrading a very old SVN version

 

 

On Dec 13, 2017, at 10:01, Joanne Giammo 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.

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

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Upgrading a very old SVN version

Mark Phippard-3
In reply to this post by Joanne Giammo
On Wed, Dec 13, 2017 at 11:01 AM, Joanne Giammo <[hidden email]> 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.

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.


--
Reply | Threaded
Open this post in threaded view
|

Re: Upgrading a very old SVN version

Nico Kadel-Garcia-2
On Wed, Dec 13, 2017 at 2:27 PM, Mark Phippard <[hidden email]> wrote:

> On Wed, Dec 13, 2017 at 11:01 AM, Joanne Giammo <[hidden email]> 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/
Reply | Threaded
Open this post in threaded view
|

Re: Upgrading a very old SVN version

AndreasMohr
On Wed, Dec 13, 2017 at 05:19:50PM -0500, Nico Kadel-Garcia wrote:

> On Wed, Dec 13, 2017 at 2:27 PM, Mark Phippard <[hidden email]> wrote:
> > 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
Reply | Threaded
Open this post in threaded view
|

Re: Upgrading a very old SVN version

Johan Corveleyn-3
On Thu, Dec 14, 2017 at 9:01 AM, Andreas Mohr <[hidden email]> wrote:

> On Wed, Dec 13, 2017 at 05:19:50PM -0500, Nico Kadel-Garcia wrote:
>> On Wed, Dec 13, 2017 at 2:27 PM, Mark Phippard <[hidden email]> wrote:
>> > 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.

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

--
Johan