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
already locked").
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.
Cheers,
Daniel
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