Ben Reser wrote on Tue, Jul 09, 2013 at 09:17:51 -0700:
> On Thu, Jul 4, 2013 at 1:32 PM, Daniel Shahaf <danie...@elego.de> wrote:
> > David Schweikert wrote on Thu, Jul 04, 2013 at 15:04:34 +0200:
> >> I was thinking that we could use something like a "svn update
> >> --readonly", where svn doesn't any check anything on the working copy,
> >> but just applies any changes committed since the last update.
> >
> > That's a common scenario, for example it applies to:
> >
> > http://subversion.apache.org/faq.html#website-auto-update
> > https://svn.apache.org/repos/asf/subversion/trunk/tools/server-side/svnpubsub/svnwcsub.py
> >
> > so enhnacing the core to support it better is not a bad idea.[1] I'm
> > not sure whether specifically svn update --do-not-crawl-the-disk is the
> > best way forward; Johan's suggestion of a broader users@ discussion
> > might lead to identifying a better solution.
> >
> > [1] Disclaimer: y $OTHERWORK uses svnwcsub to manage >15GB of live web
> > sites (with wc's on local disk), so I have an interest here.
>
> Out of order updates shouldn't be an issue for svnwcsub, you just make
> sure you're not updating the working copy backwards in time. There's
> no reason why it has to go through each state.
>
Actually svnwcsub just updates to HEAD regardless of the revision
reported to it.
> Other post-commit hook uses and other svnpubsub clients may have a
> reason to want this to happen.
>
> The options to fix this pretty much are as follows:
>
> 2) Add a mutex within the post-commit hooks themselves in order to
> serialize them. This would mostly solve the problem because the real
No. post-commit hooks are not guaranteed to be started in order. If
a 1000 files commit precedes a 1 file commit, the "post-commit fs
procesing" (big name for "insert new records to rep-cache.db") happens
before the 1000-files-commit's post-commit starts, which could easily be
after post-commit for the 1-file-commit has ended.
> 3) Add code upstream to svnpubsub to reorder the commits. This seems
> really prone to difficulties because there may be revisions missing
> for administrative reasons and then svnpubsub would block on
> publishing the following commits. So then you'd need to make
> svnpubsub timeout and elide that commit or know how to go get the
> commit information when the commit hook never sent it. I think this
> option is way too much effort for too little improvement. Since it
> only solves the problem for svnpubsub.
>
> As far as svnpubsub goes I think we could very easily add a mutex to
> it's commit hook. Which ought to avoid any real problems.
The general solution would be to somehow invent a post-commit hook
that's guaranteed to fire in order. For example...
#!/bin/sh
REV="$2"
with lock($MUTEX_FILE):
for (i = `cat $STATE_FILE` + 1; i <= $REV; i++)
rerun=`if [ -e $IN_PROGRESS_FILE ]; then echo 1; else echo 0; fi`
touch $IN_PROGRESS_FILE
env RERUN=$rerun real-hook "$@"
rm $IN_PROGRESS_FILE
echo $i > $STATE_FILE
This resembles svnsync's algorithm. ($IN_PROGRESS_FILE is
svn:sync-currently-copying)
