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. 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.