You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Schweikert <da...@schweikert.ch> on 2013/07/04 15:04:34 UTC
Updatable svn export
Hi,
We have a svn repository with many files (more than 30'000), and need to
have the HEAD version exported to a filesystem, whenever a commit is
done.
Currently, we have implemented this with a post-commit script that does
a "svn update", but the script is rather slow. The reason is that "svn
update" apparently checks the whole tree for any local changes. In our
case, we can however guarantee that no changes are done in the working
copy.
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.
An alternative would be to implement a special mode for "svn export",
which writes a file with the exported revision number (".revision" in
the root directory, for example), and a "svn export-update" that only
fetches any changed files between the last exported version and HEAD. It
could even be a completely separate binary which uses libsvn...
What are your thoughts on this? We have computer engineering students
that could be put on such a project, but it would be great to have some
guidance on whether this is a good idea and what you would recommend
doing.
Thank you and cheers
David
Re: Updatable svn export
Posted by Daniel Shahaf <da...@elego.de>.
Daniel Shahaf wrote on Thu, Jul 04, 2013 at 23:24:55 +0300:
> David Schweikert wrote on Thu, Jul 04, 2013 at 16:00:05 +0200:
> > On Thu, Jul 04, 2013 at 15:56:45 +0200, Johan Corveleyn wrote:
> > > Beware though that post-commit hooks may be running concurrently, and
> > > your 'svn update' launched by $REV might still be running when $REV+1
> > > tries to start 'svn update'.
> >
> > I can see that it could be a problem. Not for us in this case, because
> > we serialize the post-commits anyway already with a lock file.
>
> post-commit hooks may fire out of order, ie, r5 post-commi thook may be
s/r5/r6/
> invoked *before* r5 post-commit.
Re: Updatable svn export
Posted by Daniel Shahaf <da...@elego.de>.
David Schweikert wrote on Thu, Jul 04, 2013 at 16:00:05 +0200:
> On Thu, Jul 04, 2013 at 15:56:45 +0200, Johan Corveleyn wrote:
> > Beware though that post-commit hooks may be running concurrently, and
> > your 'svn update' launched by $REV might still be running when $REV+1
> > tries to start 'svn update'.
>
> I can see that it could be a problem. Not for us in this case, because
> we serialize the post-commits anyway already with a lock file.
post-commit hooks may fire out of order, ie, r5 post-commi thook may be
invoked *before* r5 post-commit.
Re: Updatable svn export
Posted by David Schweikert <da...@schweikert.ch>.
On Thu, Jul 04, 2013 at 15:56:45 +0200, Johan Corveleyn wrote:
> Beware though that post-commit hooks may be running concurrently, and
> your 'svn update' launched by $REV might still be running when $REV+1
> tries to start 'svn update'.
I can see that it could be a problem. Not for us in this case, because
we serialize the post-commits anyway already with a lock file.
> Maybe it's best if you take this thread to the users@ list, which
> seems more appropriate to discuss this further. Larger audience of svn
> users / admins who may have developed strategies to handle that ...
Will do.
Thanks again
David
Re: Updatable svn export
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Jul 4, 2013 at 3:30 PM, David Schweikert <da...@schweikert.ch> wrote:
> Hi Johan,
>
> Thank you for your quick response!
>
> On Thu, Jul 04, 2013 at 15:18:57 +0200, Johan Corveleyn wrote:
>> > We have a svn repository with many files (more than 30'000), and need to
>> > have the HEAD version exported to a filesystem, whenever a commit is
>> > done.
>> > ...
>>
>> First thing to check IMO is whether the latest svn client isn't
>> already fast enough with a normal 'svn update'. Which svn client
>> version are you using? On what platform and filesystem?
>
> We are using Subversion 1.7.10 and the working copy is on NFS. Having it
> on the local filesystem makes it faster, but I thought that it could be
> even faster if it wouldn't traverse the whole tree.
>
>> The recently released 1.8 version has an exclusive locking mode [1],
>> which makes it very fast if you're sure that there will only be a
>> ...
>
> Thanks for the hint! This looks very useful indeed, especially with NFS.
Beware though that post-commit hooks may be running concurrently, and
your 'svn update' launched by $REV might still be running when $REV+1
tries to start 'svn update'. I believe that, with 'exclusive locking
mode', the second 'svn update' will fail fast because the first one
has the working copy exclusively locked. You'll have to handle that
somehow (if you just let the second update fail, your WC will be out
of date after the commit of $REV+1).
Maybe it's best if you take this thread to the users@ list, which
seems more appropriate to discuss this further. Larger audience of svn
users / admins who may have developed strategies to handle that ...
--
Johan
Re: Updatable svn export
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
David Schweikert wrote on Fri, Jul 05, 2013 at 08:00:54 +0200:
> On Thu, Jul 04, 2013 at 19:15:15 +0100, Andreas Stieger wrote:
> > > We are using Subversion 1.7.10 and the working copy is on NFS. Having it
> > > on the local filesystem makes it faster, but I thought that it could be
> > > even faster if it wouldn't traverse the whole tree.
> >
> > A usual solution for this is to have a working copy locally, and a
> > post-commit hook that, in addition to the update, runs rsync to the slow
> > exported file system, with the required options to exclude .svn and
> > honouring mtime for detection of changes.
>
> That's finally exactly what I did to optimize the performance. Still,
> rsync needs to walk the NFS tree, so it probably could be faster with the
> knowledge of the changesets.
You could use 'svnlook tree' to construct an argument to rsync's
'--filter' or '--files-from'.
Re: Updatable svn export
Posted by David Schweikert <da...@schweikert.ch>.
On Thu, Jul 04, 2013 at 19:15:15 +0100, Andreas Stieger wrote:
> > We are using Subversion 1.7.10 and the working copy is on NFS. Having it
> > on the local filesystem makes it faster, but I thought that it could be
> > even faster if it wouldn't traverse the whole tree.
>
> A usual solution for this is to have a working copy locally, and a
> post-commit hook that, in addition to the update, runs rsync to the slow
> exported file system, with the required options to exclude .svn and
> honouring mtime for detection of changes.
That's finally exactly what I did to optimize the performance. Still,
rsync needs to walk the NFS tree, so it probably could be faster with the
knowledge of the changesets.
Cheers
David
Re: Updatable svn export
Posted by Andreas Stieger <an...@gmx.de>.
On 04/07/13 14:30, David Schweikert wrote:
> On Thu, Jul 04, 2013 at 15:18:57 +0200, Johan Corveleyn wrote:
>>> We have a svn repository with many files (more than 30'000), and need to
>>> have the HEAD version exported to a filesystem, whenever a commit is
>>> done.
>>> ...
>> First thing to check IMO is whether the latest svn client isn't
>> already fast enough with a normal 'svn update'. Which svn client
>> version are you using? On what platform and filesystem?
> We are using Subversion 1.7.10 and the working copy is on NFS. Having it
> on the local filesystem makes it faster, but I thought that it could be
> even faster if it wouldn't traverse the whole tree.
A usual solution for this is to have a working copy locally, and a
post-commit hook that, in addition to the update, runs rsync to the slow
exported file system, with the required options to exclude .svn and
honouring mtime for detection of changes.
With kind regards,
Andreas Stieger
Re: Updatable svn export
Posted by David Schweikert <da...@schweikert.ch>.
Hi Johan,
Thank you for your quick response!
On Thu, Jul 04, 2013 at 15:18:57 +0200, Johan Corveleyn wrote:
> > We have a svn repository with many files (more than 30'000), and need to
> > have the HEAD version exported to a filesystem, whenever a commit is
> > done.
> > ...
>
> First thing to check IMO is whether the latest svn client isn't
> already fast enough with a normal 'svn update'. Which svn client
> version are you using? On what platform and filesystem?
We are using Subversion 1.7.10 and the working copy is on NFS. Having it
on the local filesystem makes it faster, but I thought that it could be
even faster if it wouldn't traverse the whole tree.
> The recently released 1.8 version has an exclusive locking mode [1],
> which makes it very fast if you're sure that there will only be a
> ...
Thanks for the hint! This looks very useful indeed, especially with NFS.
Cheers
David
Re: Updatable svn export
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Jul 4, 2013 at 3:04 PM, David Schweikert <da...@schweikert.ch> wrote:
> Hi,
>
> We have a svn repository with many files (more than 30'000), and need to
> have the HEAD version exported to a filesystem, whenever a commit is
> done.
>
> Currently, we have implemented this with a post-commit script that does
> a "svn update", but the script is rather slow. The reason is that "svn
> update" apparently checks the whole tree for any local changes. In our
> case, we can however guarantee that no changes are done in the working
> copy.
>
> 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.
>
> An alternative would be to implement a special mode for "svn export",
> which writes a file with the exported revision number (".revision" in
> the root directory, for example), and a "svn export-update" that only
> fetches any changed files between the last exported version and HEAD. It
> could even be a completely separate binary which uses libsvn...
>
> What are your thoughts on this? We have computer engineering students
> that could be put on such a project, but it would be great to have some
> guidance on whether this is a good idea and what you would recommend
> doing.
First thing to check IMO is whether the latest svn client isn't
already fast enough with a normal 'svn update'. Which svn client
version are you using? On what platform and filesystem?
The recently released 1.8 version has an exclusive locking mode [1],
which makes it very fast if you're sure that there will only be a
single process accessing the working copy simultaneously. Also, make
sure that the timestamps of the on-disk files are not changed by some
other process after the checkout or update (otherwise, svn has to read
/ checksum the file contents to make sure they weren't changed --- if
both filesize and last-mod-time remain unchanged after
checkout/update, svn will optimize this, assuming the file wasn't
changed).
[1] http://subversion.apache.org/docs/release-notes/1.8.html#exclusivelocking
--
Johan
AW: Updatable svn export
Posted by Markus Schaber <m....@codesys.com>.
Hi, David,
Von: David Schweikert [mailto:david@schweikert.ch]
> We have a svn repository with many files (more than 30'000), and need to have
> the HEAD version exported to a filesystem, whenever a commit is done.
>
> Currently, we have implemented this with a post-commit script that does a
> "svn update", but the script is rather slow. The reason is that "svn update"
> apparently checks the whole tree for any local changes. In our case, we can
> however guarantee that no changes are done in the working copy.
>
> 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.
>
> An alternative would be to implement a special mode for "svn export", which
> writes a file with the exported revision number (".revision" in the root
> directory, for example), and a "svn export-update" that only fetches any
> changed files between the last exported version and HEAD. It could even be a
> completely separate binary which uses libsvn...
>
> What are your thoughts on this? We have computer engineering students that
> could be put on such a project, but it would be great to have some guidance
> on whether this is a good idea and what you would recommend doing.
A tool like this should be reasonably easy to implement using the SVN APIs
(or language bindings). You could fetch the log, check which pathes are
added/removed/changed, and fetch the added/changed files via "cat"
functionality.
However, if your files are big and the network is slow, this might be
actually much slower than update, because it transfers the whole files
instead of just the differences.
Best regards
Markus Schaber
CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
AW: Updatable svn export
Posted by Markus Schaber <m....@codesys.com>.
Hi, Bert,
Von: Bert Huijben [mailto:bert@qqmail.nl]
> From: Markus Schaber [mailto:m.schaber@codesys.com]
> > Von: Daniel Shahaf [mailto:danielsh@elego.de]
> > > 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.
> >
> > Is it really always crawling the whole working copy? It could do so
> > later, and just for the nodes which were actually touched by the
> > update.
>
> As part of the update we report which version of which nodes exist in
> the working copy. Ideally the working copy contains a single revision
> and no switched paths, in which case there is not much to report, but
> in other cases this report can get bigger.
>
> Without this report the server can't 'minimally describe' the changes
> needed.
>
> And getting a full checkout would be much slower than a local crawl
> (which is just reading wc.db, plus in many cases a local exists check
> to restore missing nodes).
But I think this step only needs to access the working copy database,
not the actual files, as the diff sent by the server is against BASE and
not WORKING (which the server cannot know about).
Best regards
Markus Schaber
CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
RE: Updatable svn export
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Markus Schaber [mailto:m.schaber@codesys.com]
> Sent: dinsdag 9 juli 2013 17:09
> To: Daniel Shahaf; David Schweikert
> Cc: dev@subversion.apache.org
> Subject: AW: Updatable svn export
>
> Hi,
>
> Von: Daniel Shahaf [mailto:danielsh@elego.de]
>
> > 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.
>
> Is it really always crawling the whole working copy? It could do so later,
> and just for the nodes which were actually touched by the update.
As part of the update we report which version of which nodes exist in the
working copy. Ideally the working copy contains a single revision and no
switched paths, in which case there is not much to report, but in other
cases this report can get bigger.
Without this report the server can't 'minimally describe' the changes
needed.
And getting a full checkout would be much slower than a local crawl (which
is just reading wc.db, plus in many cases a local exists check to restore
missing nodes).
Bert
AW: Updatable svn export
Posted by Markus Schaber <m....@codesys.com>.
Hi,
Von: Daniel Shahaf [mailto:danielsh@elego.de]
> 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.
Is it really always crawling the whole working copy? It could do so later,
and just for the nodes which were actually touched by the update.
> [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.
Best regards
Markus Schaber
CODESYS(r) a trademark of 3S-Smart Software Solutions GmbH
Inspiring Automation Solutions
3S-Smart Software Solutions GmbH
Dipl.-Inf. Markus Schaber | Product Development Core Technology
Memminger Str. 151 | 87439 Kempten | Germany
Tel. +49-831-54031-979 | Fax +49-831-54031-50
E-Mail: m.schaber@codesys.com | Web: http://www.codesys.com | CODESYS store: http://store.codesys.com
CODESYS forum: http://forum.codesys.com
Managing Directors: Dipl.Inf. Dieter Hess, Dipl.Inf. Manfred Werner | Trade register: Kempten HRB 6186 | Tax ID No.: DE 167014915
Re: Updatable svn export
Posted by Daniel Shahaf <da...@elego.de>.
Ben Reser wrote on Tue, Jul 09, 2013 at 09:17:51 -0700:
> On Thu, Jul 4, 2013 at 1:32 PM, Daniel Shahaf <da...@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)
Re: Updatable svn export
Posted by Ben Reser <be...@reser.org>.
On Thu, Jul 4, 2013 at 1:32 PM, Daniel Shahaf <da...@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.
Re: Updatable svn export
Posted by Daniel Shahaf <da...@elego.de>.
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.