On Wed, Dec 14, 2011 at 6:54 AM, Ulrich Eckhardt <ulrich.eckha...@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. > ************************************************************************************** >
