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 6086D1055E for ; Fri, 12 Apr 2013 14:10:16 +0000 (UTC) Received: (qmail 89854 invoked by uid 500); 12 Apr 2013 14:10:15 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 89818 invoked by uid 500); 12 Apr 2013 14:10:15 -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 89810 invoked by uid 99); 12 Apr 2013 14:10:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Apr 2013 14:10:15 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of andy.levy@gmail.com designates 209.85.214.180 as permitted sender) Received: from [209.85.214.180] (HELO mail-ob0-f180.google.com) (209.85.214.180) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 12 Apr 2013 14:10:10 +0000 Received: by mail-ob0-f180.google.com with SMTP id un3so2348860obb.39 for ; Fri, 12 Apr 2013 07:09:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=b0kjgEVa48nUl5OZvuDK9iqYbhvcpchziHnMe10k2rs=; b=asZmfHKYUZR3slAKNwbQMLZV8Zf6+FB9dkwXRH+74xJfjW9EMzFqH7sYbVp4OtR7XP HaE+Bevoev7Kb/o4EdWBTMcSYdrUMDrbXtI63m62BoX2Zm2K5xOmJzuxxdnL1yF6AP3K At3ZBjWboZT63GkPg3qVMqyOAbCAT3/4Fudv2PfwzDNk6rm9Jy5egiEE0vDAANjBdl50 SYCwYZi5wDVu+dXg2pYuDv8Gyk/A+mLX13c/USWuITmhd4ztESf4UFWs+0fRjLD4SSp1 5kTnfHoaxv5peK9z8iXnySFYTgP1lJeh0+8IJE3a4J7qaTHqCI2mOYABVSBoco08rnrM hXtQ== X-Received: by 10.60.173.144 with SMTP id bk16mr3853749oec.103.1365775788836; Fri, 12 Apr 2013 07:09:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.21.67 with HTTP; Fri, 12 Apr 2013 07:09:08 -0700 (PDT) In-Reply-To: References: From: Andy Levy Date: Fri, 12 Apr 2013 10:09:08 -0400 Message-ID: Subject: Re: Dealing with binaries and migrating a 36G repository To: James Marcus Cc: "users@subversion.apache.org" Content-Type: multipart/alternative; boundary=089e0118435abc963e04da2a74c8 X-Virus-Checked: Checked by ClamAV on apache.org --089e0118435abc963e04da2a74c8 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Apr 12, 2013 at 9:56 AM, James Marcus wrote: > Hi, > I have been trying to migrate a hosted repository that is 36G. This is > difficult because we have offshore teams, so the repository is almost > always active. Before I got here, it seems that someone had the build > process check in each binary after it was built.... Urgh! > > I'm looking for tips on migrating this repository? > > I have a list of the revisions that are greater then 10M > > I have looked for svndump filters to exclude certain revisions, and > considered other migration paths, but exporting 36G then scp'ing it off to > another host takes a long time and I think it would be best if I could > export everything except the binaries.. Is there a way to do this with > svndump? > Could you do this? 1) Dump the current repository up to a revision after the point where people stopped committing binaries in the build process 2) Filter out the revisions from the dumpfile 3) Load the result into a repository on the new server 4) Use svnsync to catch the new repository up (and keep in sync) 5) Cut over to the new server when you're satisfied everything is running well --089e0118435abc963e04da2a74c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Apr 12, 2013 at 9:56 AM, James Marcus <= ;marcus.james@g= mail.com> wrote:
Hi,
I have been trying = to migrate a hosted repository that is 36G. =A0This is difficult because we= have offshore teams, so the repository is almost always active. =A0Before = I got here, it seems that someone had the build process check in each binar= y after it was built.... Urgh!

I'm looking for tips on migrating this repository?<= /div>

I have a list of the revisions that are greater th= en 10M

I have looked for svndump filters to exclud= e certain revisions, and considered other migration paths, but exporting 36= G then scp'ing it off to another host takes a long time and I think it = would be best if I =A0could export everything except the binaries.. Is ther= e a way to do this with svndump?

Could you do this?

1) Dump t= he current repository up to a revision after the point where people stopped= committing binaries in the build process
2) Filter out the revisions from the dumpf= ile
3) Load the result into a reposit= ory on the new server
4) Use svnsync = to catch the new repository up (and keep in sync)
5) Cut over to the new server when you'= ;re satisfied everything is running well
--089e0118435abc963e04da2a74c8--