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=2356059
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-05-28 09:39:05 CEST