[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Updatable svn export

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Thu, 4 Jul 2013 15:56:45 +0200

On Thu, Jul 4, 2013 at 3:30 PM, David Schweikert <david_at_schweikert.ch> wrote:
> Hi Johan,
>
> Thank you for your quick response!
>
> On Thu, Jul 04, 2013 at 15:18:57 +0200, Johan Corveleyn wrote:
>> > We have a svn repository with many files (more than 30'000), and need to
>> > have the HEAD version exported to a filesystem, whenever a commit is
>> > done.
>> > ...
>>
>> First thing to check IMO is whether the latest svn client isn't
>> already fast enough with a normal 'svn update'. Which svn client
>> version are you using? On what platform and filesystem?
>
> 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.
>
>> The recently released 1.8 version has an exclusive locking mode [1],
>> which makes it very fast if you're sure that there will only be a
>> ...
>
> Thanks for the hint! This looks very useful indeed, especially with NFS.

Beware though that post-commit hooks may be running concurrently, and
your 'svn update' launched by $REV might still be running when $REV+1
tries to start 'svn update'. I believe that, with 'exclusive locking
mode', the second 'svn update' will fail fast because the first one
has the working copy exclusively locked. You'll have to handle that
somehow (if you just let the second update fail, your WC will be out
of date after the commit of $REV+1).

Maybe it's best if you take this thread to the users@ list, which
seems more appropriate to discuss this further. Larger audience of svn
users / admins who may have developed strategies to handle that ...

--
Johan
Received on 2013-07-04 15:57:37 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.