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

Re: What is the easiest way to copy an existing Subversion Repository to another server?

From: Nico Kadel-Garcia <nkadel_at_gmail.com>
Date: Sun, 25 Dec 2011 16:21:28 -0500

On Wed, Dec 14, 2011 at 6:54 AM, Ulrich Eckhardt
<ulrich.eckhardt_at_dominolaser.com> wrote:
> Am 14.12.2011 05:23, schrieb Craig Burlock:
>
>> I need to create a new clone of an existing Subversion Repository to run
>> on
>> a new server. What is the easiest way of doing this?
>
>
> Apart from the mentioned dump/load and svnsync, a plain filesystem copy
> works, too, provided you either use BDB on two similar systems or FSFS for
> the repository.
>
> However, let me ask you the question if you want to move the repository or
> create a clone? The reason is that creating a clone that is not supposed to
> be a read-only mirror or backup is an error-prone operation, because the
> clone will have the same UUID but possibly a different history than the
> original.

And one of the reasons the Red Book doesn't cover it in complete
detail is that the local configurations are very sensitive to the use
of which of hte multiple access means, configurations, or scripting
operations you use. Neither "svnadmin hotcopy", nor "svnsync", nor the
"svnadmin dump" and "svnadmin load" tools will preserve file ownership
settings, especially group ownership and sgid bits. Those matter if
you try to do shared svnserve or svn_ssh, in combination with
HTTP/HTTPS access, and/or in combination with "svnserve" access.

A checklist is your friend here. Do you want master-master live
mirroring? Then you might simply pay for WanDisco's commercial product
and save a lot of work. Do you want a fallback repository that is
guaranteed to always be in sync? Again, this is not an easy problem
and you might fall back to Wandisco's tools. Do you want a live
read-only access mirror, one that may lag the actual check-in
repository for a while but never will have the "split-brain" problem?
Then svnsync on a read-only server is excellent. Do you need to have
post-commit or pre-commit scripts rely on tools that are not part of
the repository itself, such as symlinked user lists or local config
files? Then *none* of the standard replication technuques will work.

It takes thought to find out just what you want to accomplish.

> If you just want to migrate the repo to a new server, any of the above
> methods work. You should first prevent write access to the old location
> before opening the new location though, in order to avoid these differing
> histories. If copying takes too long for your users, use svnsync in the
> background. You will further need to relocate working copies to the new repo
> URL.
>
> Good luck!
>
> Uli
> **************************************************************************************
> Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
> **************************************************************************************
> Visit our website at http://www.dominolaser.com
> **************************************************************************************
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten
> bestimmt und kann vertrauliche Informationen enthalten. Bitte
> benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte
> Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf
> weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt
> werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte
> Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht
> verantwortlich.
> **************************************************************************************
>
Received on 2011-12-25 22:21:59 CET

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.