Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
Date: Fri, 5 Jul 2013 13:53:24 +0300
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: David Schweikert <david@schweikert.ch>
Cc: Andreas Stieger <andreas.stieger@gmx.de>, users@subversion.apache.org,
	Johan Corveleyn <jcorvel@gmail.com>
Subject: Re: Updatable svn export
Message-ID: <20130705105324.GC3055@lp-shahaf.local>
References: <20130704130433.GF13274@schweikert.ch>
 <CAB84uBXEP29kfEJzZCArBYo7w3B0ya_Or-dHuwjGQq3vMzTwfg@mail.gmail.com>
 <20130704133057.GG13274@schweikert.ch> <51D5BBB3.4070507@gmx.de>
 <20130705060053.GI13274@schweikert.ch>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130705060053.GI13274@schweikert.ch>
User-Agent: Mutt/1.5.18 (2008-05-17)

David Schweikert wrote on Fri, Jul 05, 2013 at 08:00:54 +0200:
> On Thu, Jul 04, 2013 at 19:15:15 +0100, Andreas Stieger wrote:
> > > We are using Subversion 1.7.10 and the working copy is on NFS. Having it
> > > on the local filesystem makes it faster, but I thought that it could be
> > > even faster if it wouldn't traverse the whole tree.
> > 
> > A usual solution for this is to have a working copy locally, and a
> > post-commit hook that, in addition to the update, runs rsync to the slow
> > exported file system, with the required options to exclude .svn and
> > honouring mtime for detection of changes.
> 
> That's finally exactly what I did to optimize the performance. Still,
> rsync needs to walk the NFS tree, so it probably could be faster with the
> knowledge of the changesets.

You could use 'svnlook tree' to construct an argument to rsync's
'--filter' or '--files-from'.