Fairchild, Gregory J - OASAM OCIO CTR wrote on Mon, 11 Mar 2019 22:22 +00:00:
> "You can avoid this by throwing a mutex around the svn(1) call (see
> flock(1))." Being that I'm pretty new to subversion, you lost me here.
It's possible for the post-commit process of rN to run in parallel to
the post-commit process of rN+1. If that happens, it's possible for the
'svn update' processes launched by the two post-commit processes to
run in parallel. If that happens, at least one of the two 'svn update'
processes will error out, probably with E155004 ("working copy is
In short, post-commit hooks need to be written to account for the fact
that Subversion does not sequence or serialize hook invocations. In
your case, that means changing «svn update $args» to «flock … svn update
$args» in order to ensure that concurrent post-commit hook runs will run
'svn update' in sequence, rather than in parallel. (The runs might
_still_ be out of order — I mean, rN+1 before rN — but your hook is
indifferent to the $REV parameter.)
flock(1) is simply a program that takes a lock, aka a mutex. It's not
standardized so you'll have to look up the flags on your system.
P.S. Having said all that, look up svnpubsub and svnwcsub in tools/ in
the source tree. They do basically what you are after with that hook.
> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s_at_daniel.shahaf.name]
> Sent: Saturday, March 09, 2019 7:22 AM
> To: Ryan Schmidt; Fairchild, Gregory J - OASAM OCIO CTR
> Cc: Subversion Users
> Subject: Re: svn:E155007:None of the tarets are working copies
> While I'm here, let me point out that post-commit runs for different
> revisions may happen in parallel or even out of order. In this case, the
> worst that could happen is that the svn(1) invocation in the second run
> will error out with E155004 and the error will be marshalled back to the
> user who committed. You can avoid this by throwing a mutex around the
> svn(1) call (see flock(1)).
Received on 2019-03-13 15:09:51 CET