[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Subversion dump/load

From: A Hemaraj <a_hemaraj_at_yahoo.com>
Date: Fri, 29 May 2009 00:51:25 -0700 (PDT)

Hi Stephen/Andy,

Thanks a lot for all your advice! Is it possible for me to migrate repositories from a lower Subversion server version to a higher version.

For e.g., If I migrate repositories from Server A (Subversion server version 1.5.x) to Server B (Subversion server version 1.3.x) using dump/load, will there be any issues?

I can upgrate my Subversion server in Server B. However, I don't want to do it right now.

Regards,

Hemaraj

--- On Thu, 5/28/09, Stephen Connolly <stephen.alan.connolly_at_gmail.com> wrote:

> From: Stephen Connolly <stephen.alan.connolly_at_gmail.com>
> Subject: Re: Subversion dump/load
> To: "A Hemaraj" <a_hemaraj_at_yahoo.com>
> Cc: "Andy Levy" <andy.levy_at_gmail.com>, users_at_subversion.tigris.org
> Date: Thursday, May 28, 2009, 1:10 PM
> There is another option, but this
> requires that your production server is upgraded to a newer
> version of svn...
>
> you could use svnsync to move the repository from server A
> to server B.
>
> with this approach, you create a pre-commit hook on the
> repo on server B to prevent any commits except from
> svnsync.
>
>
> svnsync will then pull all the transactions one at a time
> from server A to the new repo. You don't have to stop
> people working on server A, as svnsync is incremental.
>
> -Stephen
>
>
> 2009/5/28 Stephen Connolly <stephen.alan.connolly_at_gmail.com>
>
> 2009/5/28 A Hemaraj <a_hemaraj_at_yahoo.com>
>
>
> --- On Wed, 5/27/09, Andy Levy <andy.levy_at_gmail.com>
> wrote:
>
>
>
> > From: Andy Levy <andy.levy_at_gmail.com>
>
> > Subject: Re: Subversion dump/load
>
> > To: "A Hemaraj" <a_hemaraj_at_yahoo.com>
>
> > Cc: users_at_subversion.tigris.org
>
> > Date: Wednesday, May 27, 2009, 6:56 PM
>
> > On Wed, May 27, 2009 at 09:10, A
>
> > Hemaraj <a_hemaraj_at_yahoo.com>
>
> > wrote:
>
> > > Hi,
>
> > >
>
> > > I have been maintaining quite a few Subversion
>
> > repositories in the production server. I use
> "svnserve" in
>
> > production server. I need to migrate few repositories
> from
>
> > another server to the production server. I am planning
> to
>
> > migrate using "svnadmin dump" and
> "svnadmin load" commands.
>
> > Please note that I am planning to migrate the
> repositories
>
> > into a new repositories in production server without
>
> > touching the existing repositories.
>
> > >
>
> > > Production Subversion Version: 1.3.2
>
> > > Remote Server Subversion Version: 1.1.4
>
> > >
>
> > > I have the following queries:
>
> > >
>
> > > 1) Since I have very huge repositories in the
>
> > production, will the migration process (svnadmin
> dump/load)
>
> > will mess or harm my existing repositories in
> production
>
> > server?
>
> >
>
> > No, the reason for having svnadmin
> dump/load is to prevent
>
> > damage.
>
> > Just make sure you have plenty of disk space
> available.
>
> >
>
> > > 2) Do I need to stop the
> "svnserve" service?
>
> >
>
> > On which server? On the "source"
> server, I'd recommend it,
>
> > so that you
>
> > don't get any new commits made after you've
> made the
>
> > transition.
>
> >
>
> > I'd also recommend you upgrade your Production
> server.
>
> > 1.3.x is no
>
> > longer supported, nor is 1.4, and 1.4 and later
> versions of
>
> > the FSFS
>
> > back-end provide the potential for some extra space
> savings
>
> > and many
>
> > other efficiencies.
>
> >
>
>
>
> Hi Andy,
>
>
>
> Thanks for the help and advice! I will stop the
> "svnserve" service in source server before taking
> dump. Do I need to stop the "svnserve" service in
> destination server (Production server) before loading
> (svnadmin load) the repository?
>
>
>
>
> I would not stop the production server. In general,
> communication solves any issues. You just tell people
>
> "we are migrating from
> server A to server B. At hh:mm on dd-mmm-yyyy you will
> shut down SVN on server A. You will email everyone when
> the migration is complete and they can start using the
> repository on server B. The migration will not affect any
> other repositories on server B."
>
>
>
> The only reason to stop the production server is if people
> might try and commit to the repository (which you are
> loading) while you are loading it.... now keep in mind that
> the repository you are loading did not exist on your
> production server until you started loading it... so unless
> you have eager users speculatively trying to work on a
> repository which you are loading while you are loading it...
> (in my view highly unlikely) this is not an issue
>
>
>
> The easiest solution is: you just hunt down the person,
> bash them on the head
> and delete the load and restart it... hardly a major
> issue.
>
>
>
> If you don't like that solution, the next easiest way
> out of this is to to the load into a directory outside of
> the svnroot...
>
> e.g. if you have done
>
> svnserve -d -r /var/svn
>
> The really paranoid person would do
>
>
>
> svnadmin create /var/svn2/newrepo
> svnadmin load /var/svn2/newrepo < newrepo.dump
> mv /var/svn2/newrepo /var/svn
>
> Another solution is to do the load as root, keeping the
> files for newrepo owned by root... once the load is complete
> you just change the file ownership back to the svnserve
> user.
>
>
>
> -Stephen
>
>
> Thanks & Regards,
>
>
>
> Hemaraj
>
>
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2356056
>
>
>
> To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
>
>
>
>
>
>

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2356686

To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-29 09:52:23 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.