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

Re: svn relocate/move (repo not wc)

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-02-02 00:32:15 CET

On 2/1/06, Steve Williams <stevewilliams@kromestudios.com> wrote:
> Garrett Rooney wrote:
> >On 2/1/06, Steve Rieger <riegersteve@gmail.com> wrote:
> >
> >
> >>am running outta space and need to move the repo,
> >>
> >>
> >>svn switch --relocate file:////usr/svn-etc file:///var/svn/etc
> >>
> >>
> >>svn: The repository at 'file:///var/svn/etc/etc' has uuid '974675a8-
> >>c30b-0410-8a05-83431ef311a2', but the WC has '4b58393f-330b-0410-bebe-
> >>a89525468735'
> >>
> >>so whats the proper way to move a repo that will not touch the wc.
> >>
> >>
> >
> >You need to make sure the version of the repos in the new location is
> >IDENTICAL to the old one, including the UUID. If you are doing the
> >move via a dump/load, that means using the --force-uuid flag to
> >svnadmin load when loading into your new (empty) repository on the new
> >machine. If you're loading your data into an existing repository
> >(which by definition has a different UUID) you CANNOT migrate working
> >copies via switch --relocate, it simply will not work.
> >
> >
> I've done several repository moves recently from one server to another
> server where all I did was "svnadmin load newrepos <oldrepos.dump". The
> users then simply selected TortoiseSVN>Relocate, entered the new URL and
> all worked happily. So why did it not fall over for me without forcing
> the UUID on the new repository?

Ahh, now that I look at the code, the UUID record in the dumpfile will
be used even without a --force-uuid flag, if the repository is empty
when you start the load. If it already has content you have to force
it, although if that's the case doing so is probably a bad thing,
since now the rev numbers will be out of sync, so your new repository
will claim to be the same as the old one (by having hte same UUID),
but will in actuality be different, most likely breaking all sorts of


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Feb 2 00:33:48 2006

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.