RE: Planning a SVN upgrade

________________________________
From: Mark Phippard
Sent: Saturday, 24 August 2013 6:35 AM
On Fri, Aug 23, 2013 at 4:09 PM, Maureen Barger wrote:

I am currently planning an upgrade from SVN 1.5 (using svnserve and
ssh tunnel) to SVN 1.8.1 fronted with Apache and webdav using AD for
authNz.
We have about 50 repos. I'll be moving from an older Ubuntu 8 install
to Centos 6 x64.

We have just upgraded our server from 1.2.3 to 1.8.1, including a move from Apache 2.0 to Apache2.2.
It took me some time, but it was done as a bit of a background task. There were 74 BDB repositories that had to be dumped and loaded to FSFS format.

My thought was I could upgrade the SVN installation in place, bringing
the repo up to 1.8 and then dump those repos and bring them online in
the new environment.

If it were me, I would not upgrade the repositories. SVN 1.8 can just serve the old repositories. I would do the upgrade and only after I was using it for a while would I then consider to start doing a dump/load on the repositories. You could then do them one by one as desired. The main benefit in upgrading the repository is to use less disk space.
I also would not upgrade existing repositories just for the sake of it. If there's a feature you feel would be useful that's only available with the 1.8 repo format, then I would do it, but ONLY for the active repos. The only reason I upgraded the BDB repositories was because I could no longer access them with the new server software. Even then, I left them in the 1.2 format in case we had to go back to the original server for some reason.

If you're going to do an upgrade on the repositories, make sure you back them up first. Then the disk space issue becomes moot, because the backups take space as well.
We currently use Eclipse as our IDE and Jenkins as our CI tool with
Nexus as the object repo. I was thinking to leave the upgrade of
Eclipse client and svnkit to the indiviidual so they can decide what
direction to take with their working copies et al.

Yes, your clients can already be using 1.8 if they want to. There is no need to upgrade the client either before or after the server. Let the clients manage it. Only exception is if there are specific new features you want to implement across the board. If you do a lot of branching and merging, it would be a good idea for the people that do merge to all be using the same version. Likewise, there are other features that might be like this.

I concur. (Of course, Mark has a lot more SVN experience and in-depth knowledge than I do.) Leave it to the individual to decide whether to upgrade. There are very few cases where the server and client software are incompatible between versions. Mind you, I did have to do our upgrade to the server because version 1.8.x of the client doesn't play nicely with version 1.2.x of the server, in terms of adding new files and displaying logs. That's how I came to join the mailing lists in the first place.

I do not foresee
any changes I would need to make to Jenkins or Nexus.

Just the URL to access the repository will change.

Even that doesn't have to change. We're using the same URLs.

Has anyone made a jump this large before? Any comments about my upgrade plan?

There is nothing unusual about this. People have jumped from 1.1 to 1.8.

In my case, 1.2 to 1.8. By comparison, 1.5 to 1.8 should be easy.

Geoff

--
Apologies for the auto-generated legal boilerplate added by our IT department:
- The contents of this email, and any attachments, are strictly private
and confidential.
- It may contain legally privileged or sensitive information and is intended
solely for the individual or entity to which it is addressed.
- Only the intended recipient may review, reproduce, retransmit, disclose,
disseminate or otherwise use or take action in reliance upon the information
contained in this email and any attachments, with the permission of
Australian Arrow Pty. Ltd.
- If you have received this communication in error, please reply to the sender
immediately and promptly delete the email and attachments, together with
any copies, from all computers.
- It is your responsibility to scan this communication and any attached files
for computer viruses and other defects and we recommend that it be
subjected to your virus checking procedures prior to use.
- Australian Arrow Pty. Ltd. does not accept liability for any loss or damage
of any nature, howsoever caused, which may result
directly or indirectly from this communication or any attached files.