On Thu, Jul 4, 2013 at 1:32 PM, Daniel Shahaf <danielsh_at_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.
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:
1) Move post-commit inside the write lock, this forces post-commit to
be serialized just like the actual commits. However, this also has
the negative of keeping the repo locked longer than is necessary.
People with long running post-commit hooks are going to be
particularly impacted by this. I'm pretty sure the out of order
delivery is also probably impacts people with long running post-commit
hooks the most.
2) Add a mutex within the post-commit hooks themselves in order to
serialize them. This would mostly solve the problem because the real
issue here is that for OS scheduling reasons and work difference
reasons they may not finish in the same order they're started. E.G. a
really big commit is followed by a really small commit. Again this
would still slow clients since clients wait for the post-commit hook
to finish because the client waits for the post-commit hook to finish
so the server can marshall errors back to the client. Unlike the
previous option this would still allow for the possibility of out of
ordering since there would be a race between each post-commit in
getting the mutex. However, because they are always started in the
proper order due to the repository write lock, I don't think in
practice we would actually see this problem. The real disadvantage of
this strategy is that every commit hook has to have it's own
implementation.
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.
Received on 2013-07-09 18:18:30 CEST