From users-return-4049-daniel=haxx.se@subversion.apache.org Mon Aug 2 16:21:10 2010 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on giant.haxx.se X-Spam-Level: X-Spam-Status: No, score=-4.5 required=3.0 tests=BAYES_00,DS_FRIEND autolearn=ham version=3.3.1 Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by giant.haxx.se (8.14.3/8.14.3/Debian-9.1) with SMTP id o72EL8DS025837 for ; Mon, 2 Aug 2010 16:21:09 +0200 Received: (qmail 2476 invoked by uid 500); 2 Aug 2010 14:20:58 -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 2469 invoked by uid 99); 2 Aug 2010 14:20:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Aug 2010 14:20:57 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS Received-SPF: pass (athena.apache.org: local policy) Received: from [192.109.42.8] (HELO einhorn.in-berlin.de) (192.109.42.8) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 02 Aug 2010 14:20:51 +0000 X-Envelope-From: stsp@stsp.name Received: from ted.stsp.name (ted.stsp.name [217.197.84.34]) by einhorn.in-berlin.de (8.13.6/8.13.6/Debian-1) with ESMTP id o72EKL6N004917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Aug 2010 16:20:22 +0200 Received: from ted.stsp.name (stsp@localhost [127.0.0.1]) by ted.stsp.name (8.14.3/8.14.3) with ESMTP id o72EKL69015588; Mon, 2 Aug 2010 16:20:21 +0200 (CEST) Received: (from stsp@localhost) by ted.stsp.name (8.14.3/8.14.3/Submit) id o72EKJ7C027703; Mon, 2 Aug 2010 16:20:19 +0200 (CEST) Date: Mon, 2 Aug 2010 16:20:19 +0200 From: "'Stefan Sperling'" To: Giulio Troccoli Cc: "'Nico Kadel-Garcia'" , "=?iso-8859-1?Q?'Tenneb=F8?= Frode'" , "'Istace Emmanuel'" , "users@subversion.apache.org" Subject: Re: SVN "Relay" Message-ID: <20100802142019.GD3967@ted.stsp.name> Mail-Followup-To: Giulio Troccoli , 'Nico Kadel-Garcia' , =?iso-8859-1?Q?'Tenneb=F8?= Frode' , 'Istace Emmanuel' , "users@subversion.apache.org" References: <63382D15-E37D-4E62-8525-ADFFB6327942@ryandesign.com> <9B21F0BBE52BF74DBA71AB889C021DD702FB4315@exisland01.omnifone.com> <72C7757E81EE204B8BF4317BC542AA110376ED65@corpappl746.corp.saab.se> <20100802123153.GC3967@ted.stsp.name> <6680A70380E6BA44A2D94ED7085718EE236708D8A8@ln1exc03> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6680A70380E6BA44A2D94ED7085718EE236708D8A8@ln1exc03> User-Agent: Mutt/1.5.20 (2009-06-14) X-Scanned-By: MIMEDefang_at_IN-Berlin_e.V. on 192.109.42.8 X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.3.5 (giant.haxx.se [80.67.6.50]); Mon, 02 Aug 2010 16:21:10 +0200 (CEST) X-Friend: Friend On Mon, Aug 02, 2010 at 01:40:38PM +0100, Giulio Troccoli wrote: > > > And if you decide to use svnsync for mirroring, note that the > > way the book describes the mirroring setup is vulnerable to a > > race condition. > > Make sure to read this issue: > > http://subversion.tigris.org/issues/show_bug.cgi?id=3546 > > To avoid the problem described in issue #3546, you should > > make the mirror repository pull changes from the master via a > > cronjob, and synchronise svnsync jobs using a file lock on > > the computer hosting the mirror repository. > > Only one svnsync job must be writing to the mirror repository > > at a time, or you risk breaking sync jobs. So do not push > > revisions from the master to the mirror via the post-commit > > hook (which is what the book suggests). > > Something like the following should work from a crontab on > > Linux systems: > > 0 * * * * flock -w 60 /tmp/svnsync.lock svnsync sync > > file:///path/to/repository/mirror > > > > We're working on fixing this problem such that the way the > > book describes it will work without a race condition, but > > that work is not yet complete. > > A bit OT, I just want to check that this (the race condition) does not > apply to two svnsync processes trying to sync two different > repositories. Unless both svnsync processes are writing to the same repository, the race condition cannot trigger. > I use svnsync to keep our DR server up-to-date. We have very few > people committing to the various repositories so it's more likely (and > still it's not that likely) that two people commit to two different > repositories than to the same one, so I just wanted to check thise > scenario with you. It has nothing much to do with when commits happen. The problem is that two svnsync processes running simultaneously (for whatever reason) can corrupt svnsync meta-data, causing subsequent syncs to fail because the actual latest revision in the repository doesn't match what svnsync expects. See here for a more detailed description of the problem: http://www.mail-archive.com/dev@subversion.apache.org/msg00265.html Stefan