You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by David Aldrich <Da...@EU.NEC.COM> on 2008/09/26 12:55:23 UTC

Subversion 1.4.6 -> 1.5.2 migration - sanity check please

Hi

We are planning to upgrade our svn server from 1.4.6 to 1.5.2. We are checking what is necessary to be done and would be grateful for comments on our plan.

We have multiple repositories (one for each of our projects) in FSFS format.

The plan is:

1) Install svn 1.5.2 onto new server hardware, running under Centos 5.0

2) Notify users and disable access to 1.4.6 server

3) Backup each repository using 'svnadmin dump' (or could use tar - I) and restore onto the new server

4) Run both svnadmin upgrade and svn-populate-node-origins-index on each repository

5) Map existing http: url to point to new server

6) Notify users that new server is up and running.

Users will remain at 1.4.6 client for now. I see no reason for them to commit modified files prior to the upgrade.

Some file locks may be active, do we need to look after those in some special way?

Anything else we've forgotten?

Best regards

David

Re: Subversion 1.4.6 -> 1.5.2 migration - sanity check please

Posted by Andy Levy <an...@gmail.com>.
On Fri, Sep 26, 2008 at 08:55, David Aldrich <Da...@eu.nec.com> wrote:
> Hi
>
> We are planning to upgrade our svn server from 1.4.6 to 1.5.2. We are
> checking what is necessary to be done and would be grateful for comments on
> our plan.
>
> We have multiple repositories (one for each of our projects) in FSFS format.
>
> The plan is:
>
> 1) Install svn 1.5.2 onto new server hardware, running under Centos 5.0
>
> 2) Notify users and disable access to 1.4.6 server
>
> 3) Backup each repository using 'svnadmin dump' (or could use tar - I) and
> restore onto the new server
>
> 4) Run both svnadmin upgrade and svn-populate-node-origins-index on each
> repository

If you use svnadmin dump in 1.4.6 on the old server and svnadmin
create + svnadmin load in 1.5.2 on the new server, then step 4
shouldn't be needed.

> 5) Map existing http: url to point to new server
>
> 6) Notify users that new server is up and running.
>
> Users will remain at 1.4.6 client for now. I see no reason for them to
> commit modified files prior to the upgrade.
>
> Some file locks may be active, do we need to look after those in some
> special way?

Locks aren't maintained in the dumpfile. My personal preference would
be to get people to release all their locks (thus committing their
changes as well). I'm not sure if there's a "right" way to carry them
over.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

RE: Subversion 1.4.6 -> 1.5.2 migration - sanity check please

Posted by Erik Hemdal <er...@comprehensivepower.com>.

> -----Original Message-----
> From: David Aldrich [mailto:David.Aldrich@EU.NEC.COM] 
> Sent: Friday, September 26, 2008 9:40 AM
> To: Sholokhov, Vitaliy; users@subversion.tigris.org
> Subject: RE: Subversion 1.4.6 -> 1.5.2 migration - sanity check please
> 
> 
> Hi Vitaliy
> 
> Thanks for your reply.
> 
> > There's no reason to do such heavy lifting with migration
> 
> Well, we want to move to new hardware, so it is appropriate for us.
> 
> David

If you have the time, it's always nice to be able to check that you can
recover from a backup, move a repository, etc.  Moving to new hardware gives
you a great opportunity to make sure everything is healthy.

I, for one, would appreciate hearing back if you run into anything
unexpected.  Good luck with the upgrade.

Erik



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org


RE: Subversion 1.4.6 -> 1.5.2 migration - sanity check please

Posted by David Aldrich <Da...@EU.NEC.COM>.
Hi Vitaliy

Thanks for your reply.

> There's no reason to do such heavy lifting with migration

Well, we want to move to new hardware, so it is appropriate for us.

David

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org


RE: Subversion 1.4.6 -> 1.5.2 migration - sanity check please

Posted by "Sholokhov, Vitaliy" <vs...@marvel.com>.
We've installed subversion 1.5 server on top of 1.4.6 without any
problems (while keeping repositories at 1.4 version). 

There's no reason to do such heavy lifting with migration. It all works
out transparently. 

 

P.S. Backups never hurt anyone in any case scenario ;-)

 

________________________________

From: David Aldrich [mailto:David.Aldrich@EU.NEC.COM] 
Sent: Friday, September 26, 2008 8:55 AM
To: users@subversion.tigris.org
Subject: Subversion 1.4.6 -> 1.5.2 migration - sanity check please

 

Hi

 

We are planning to upgrade our svn server from 1.4.6 to 1.5.2. We are
checking what is necessary to be done and would be grateful for comments
on our plan.

 

We have multiple repositories (one for each of our projects) in FSFS
format.

 

The plan is:

 

1) Install svn 1.5.2 onto new server hardware, running under Centos 5.0

 

2) Notify users and disable access to 1.4.6 server

 

3) Backup each repository using 'svnadmin dump' (or could use tar - I)
and restore onto the new server 

 

4) Run both svnadmin upgrade and svn-populate-node-origins-index on each
repository

 

5) Map existing http: url to point to new server

 

6) Notify users that new server is up and running.

 

Users will remain at 1.4.6 client for now. I see no reason for them to
commit modified files prior to the upgrade.

 

Some file locks may be active, do we need to look after those in some
special way?

 

Anything else we've forgotten?

 

Best regards

 

David


******************************************************************************
Nothing contained in this e-mail shall (a) be considered a legally binding agreement, amendment or modification of any agreement with Marvel, each of which requires a fully executed agreement to be received by Marvel or (b) be deemed approval of any product, packaging, advertising or promotion material, which may only come from Marvel's Legal Department.
******************************************************************************
THINK GREEN - SAVE PAPER - THINK BEFORE YOU PRINT!