Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C6BEA184F0 for ; Wed, 11 Nov 2015 12:53:50 +0000 (UTC) Received: (qmail 93639 invoked by uid 500); 11 Nov 2015 12:53:50 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 93592 invoked by uid 500); 11 Nov 2015 12:53:50 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 93581 invoked by uid 99); 11 Nov 2015 12:53:50 -0000 Received: from Unknown (HELO spamd2-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Nov 2015 12:53:50 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd2-us-west.apache.org (ASF Mail Server at spamd2-us-west.apache.org) with ESMTP id 8D8F41A2CF1 for ; Wed, 11 Nov 2015 12:53:49 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd2-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -0.099 X-Spam-Level: X-Spam-Status: No, score=-0.099 tagged_above=-999 required=6.31 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=disabled Authentication-Results: spamd2-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-eu-west.apache.org ([10.40.0.8]) by localhost (spamd2-us-west.apache.org [10.40.0.9]) (amavisd-new, port 10024) with ESMTP id KjqBdq7a7XLo for ; Wed, 11 Nov 2015 12:53:39 +0000 (UTC) Received: from mail-lf0-f52.google.com (mail-lf0-f52.google.com [209.85.215.52]) by mx1-eu-west.apache.org (ASF Mail Server at mx1-eu-west.apache.org) with ESMTPS id 927E921277 for ; Wed, 11 Nov 2015 12:53:38 +0000 (UTC) Received: by lfs39 with SMTP id 39so15589567lfs.3 for ; Wed, 11 Nov 2015 04:53:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QXWklAlq86/eOfL3nkhS52fGYwyo+sjYD7LvAqjyikM=; b=zHSis3FyxrBQWdSFLX7v1lvGDigjoqFPUblkBeXQucbkNxDnUzzmA2EoHThxT+/gOx 6GXCyTbpYbYQE/cZD4VO0421o5Gj4HbxKH2SgPWUNwZR5iLtY3ccAtX3BBG7ihvMQZIV YMTAjJ/fhDWHNbUvgnuLxqvQHiKm/YuhdYJtP/9VQFK5WJ6T6AuEX9LJ9+KV8j4HGPu/ 5dOgqzjDLQVw7kqySTWytmANGS/MYjP86zbLiDuOrfvl6jUbe7TwjK/83Tj6HokEhEcH z7i/KWLvN5EZQvg8NogF5S+J57YiAJAXmIUcKm27IoULhCbUnuyigDuRcJNdrJ+g/8ct lqlg== MIME-Version: 1.0 X-Received: by 10.25.15.213 with SMTP id 82mr4291278lfp.98.1447246412407; Wed, 11 Nov 2015 04:53:32 -0800 (PST) Received: by 10.25.206.206 with HTTP; Wed, 11 Nov 2015 04:53:32 -0800 (PST) In-Reply-To: References: Date: Wed, 11 Nov 2015 07:53:32 -0500 Message-ID: Subject: Re: Temporary repository. From: Nico Kadel-Garcia To: Andreas Stieger Cc: Jason Morgan , "users@subversion.apache.org" Content-Type: text/plain; charset=UTF-8 On Wed, Nov 11, 2015 at 3:51 AM, Andreas Stieger wrote: > Hi, > >> due, to a datacentre migration , a temporary SVN repository was set up to allow devs to continue working for a week or two. >> >> When the PROD SVN repository is brought online what is the best method of adding the changes in the temporary repository back in to the Prod SVN repository ? > > Depending on your specific procedural requirements (relating to downtime etc), svnadmin dump/load, svnrdump dump/load or svnsync. > http://svnbook.red-bean.com/en/1.7/svn-book.html#svn.reposadmin.maint.migrate > The capable administrator can perform this completely transparent to users. > > Andreas svnadmin dump/load does not bring commit scripts or file ownership. It can also require downtime, and careful handling for updating the replica. svnsync can be a bit more graceful about keeping a slave up-to-date until the final moment, but also takes attention to make sure all the hook-scripts and file ownership and .conf files get replicated correctly. If you're not changing the version of Subversion on the servers in the process, it can often be safest and fastest to simply "rsync" the content, schedule a switchover, *move aside* and disable access to to the original server, take a final backup, and only then enable access to the remote server.