You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by mi...@agilent.com on 2011/12/14 17:55:05 UTC
svn ci performance issue with 1.7.x and nfs mounted working copies
I originally sent this to users@ but didn't get any response. Trying dev@. I'm really starting to get some pushback from our engineers wanting to go back to 1.6.x because of pretty severe performance slowdowns.
In addition to slow "svn rm" commands we are seeing some pretty severe slowdowns for "svn ci" as well. For example, here is an interesting situation. I want to checkin a single file in my repository. If I run "svn ci" from the root of my working copy it takes 1m11s to complete. However if I instead run
cd <root of working copy>
svn st
cd subdir
svn ci
cd <root of working copy>
svn up
That whole set of commands takes 16s to run. The actual change I am committing is adding or deleting a single line of a very small script. I am trying to simulate what a top level "svn ci" script would do with the commands I have above.
Here are the stats for my working copy. As generated by my checkSVNSize.sh script.
digital/mixedsignal/analog_model/analog_model_vams/netlist/hh1a|210
5393
0
0
My checkSVNSize.sh script runs the following queries
sqlite3 .svn/wc.db "select parent_relpath, count(*) AS n from nodes group by parent_relpath order by n desc limit 1"
sqlite3 .svn/wc.db "select count (*) from nodes"
sqlite3 .svn/wc.db "select count (*) from nodes where op_depth > 0"
sqlite3 .svn/wc.db "select count (*) from actual_node"
Michael Rytting
Agilent Technologies
michael_rytting@agilent.com<ma...@agilent.com>
719-590-3708
Michael Rytting
Agilent Technologies
michael_rytting@agilent.com<ma...@agilent.com>
719-590-3708
RE: svn ci performance issue with 1.7.x and nfs mounted working
copies
Posted by "Moe, Mark" <ma...@medtronic.com>.
> I don't really know how to proceed. The performance gains are huge
> on NFS and it's hard to see any other way to fix the 1.7 regression.
> We could sacrifice concurrency for performance and enable it all the
> time, essentially deciding that this is the way that WCNG will use
> SQLite.
I don't really have a vote, but if I did, it would very much be in favor of the performance gains. For NFS based working-copies, this SQLite "locking_mode = exclusive" change turns a big v1.7 performance loss into a big gain. It also seems to improve performance for local disk working-copies too.
- Mark
[CONFIDENTIALITY AND PRIVACY NOTICE]
Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records.
To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com
Re: svn ci performance issue with 1.7.x and nfs mounted working copies
Posted by Philip Martin <ph...@wandisco.com>.
"Moe, Mark" <ma...@medtronic.com> writes:
> Yes, I tried it and it was very effective! See below:
>
> 1.6.17 1.7.4 1.7.4-patched
> NFS benchmark* 1534s 4074s 572s
> Local benchmark* 365s 162s 118s
> NFS svn co 29s 163s 18s
> Local svn co 4s 4s 3s
>
> Are there any downsides to this patch? It sounds like the only
> downside is a delay to simultaneous read operations for the same
> working-copy. Those operations are very rare for compared to the huge
> gains in NFS working-copy performance.
It probably rare in a Unix command line environment. GUI environments
are more difficult, it's not hard to imagine GUIs that run status to
update one window while update runs in another, and those windows could
show the same working copy. I don't know whether the current GUIs do
behave that way since the current concurrency isn't perfect: run status
during update and if a work-queue item exists then status will fail.
The other question is how well locking works on NFS. If we add this
feature will it break existing setups? Is exclusive locking more or less
reliable than the current locking? My guess is that exclusive locking is
already part of the current system and so exclusive locking is at least
as reliable as the current system.
> * The benchmark command runs a variety of svn commands and is from here https://ctf.open.collab.net/sf/wiki/do/viewPage/projects.csvn/wiki/BenchmarkInstructions.
I know it works on test case benchmarks, I'm more interested in numbers
from a real use cases. However, it is good to know that it works on
systems other than my own NFS setup.
I don't really know how to proceed. The performance gains are huge
on NFS and it's hard to see any other way to fix the 1.7 regression.
We could sacrifice concurrency for performance and enable it all the
time, essentially deciding that this is the way that WCNG will use
SQLite.
I suppose we could try to enable it automatically if appropriate, but I
don't know what test we use to make the decision. The alternative is to
make it user controllable via .subversion/config but there is opposition
to adding such controls. That raises the questions what is the default
and what do we recommend people use?
--
Philip
Re: svn ci performance issue with 1.7.x and nfs mounted working copies
Posted by Johan Corveleyn <jc...@gmail.com>.
On Tue, May 15, 2012 at 7:55 PM, Moe, Mark <ma...@medtronic.com> wrote:
>> I rewrote some parts of the commit processing on trunk last week, which
>> should have a positive effect on the use cases reported in this thread.
>
>> Is it possible for somebody to see what the performance difference on NFS
>> is?
>
> Does this include Phillip's patch (http://subversion.tigris.org/issues/show_bug.cgi?id=4176) or is this a similar performance improvement not related to that patch?
>
> Please excuse my question; I'm new to testing the source: if I compile the trunk (http://svn.apache.org/repos/asf/subversion/trunk/), then am I getting a lot of changes compared with the release v1.7.4? I'm asking because I wonder if it would be better to test Bert's changes directly applied to v1.7.4 (with or without Philip's patch for bug 4176) for comparison sake.
>
I don't know the extent of Bert's changes in this area, but it's
likely that it will not be easy to backport that to the 1.7.x
codebase. But if it is backportable, sure, that would be a good
comparison ...
Another possible useful comparison could be to compare "trunk" with
"trunk-without-Bert's-changes".
> [CONFIDENTIALITY AND PRIVACY NOTICE]
[snip]
Please do not send such legal boilerplate, it doesn't make any sense
on a public (and archived) mailinglist. If you're forced to use it by
your company, you should probably get and use another email address
for these mailinglists ...
--
Johan
RE: svn ci performance issue with 1.7.x and nfs mounted working
copies
Posted by "Moe, Mark" <ma...@medtronic.com>.
> I rewrote some parts of the commit processing on trunk last week, which
> should have a positive effect on the use cases reported in this thread.
> Is it possible for somebody to see what the performance difference on NFS
> is?
Does this include Phillip's patch (http://subversion.tigris.org/issues/show_bug.cgi?id=4176) or is this a similar performance improvement not related to that patch?
Please excuse my question; I'm new to testing the source: if I compile the trunk (http://svn.apache.org/repos/asf/subversion/trunk/), then am I getting a lot of changes compared with the release v1.7.4? I'm asking because I wonder if it would be better to test Bert's changes directly applied to v1.7.4 (with or without Philip's patch for bug 4176) for comparison sake.
Thanks,
- Mark
[CONFIDENTIALITY AND PRIVACY NOTICE]
Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records.
To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com
RE: svn ci performance issue with 1.7.x and nfs mounted working copies
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: vrijdag 4 mei 2012 21:15
> To: Moe, Mark
> Cc: Philip Martin; dev@subversion.apache.org; Braun, Eric
> Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working
> copies
>
> Well... your interest has already been noted :-) Maybe you're asking
> how you can help get the bug fixed? Volunteering, of course (as we all
> are).
>
> Philip noted a couple problems in the bug report. Focusing on how to
> resolve those is likely the start of the work. I imagine at least two
> approaches: ensure the same underlying wc_db instance is used in both
> cases, or that we have a way to open non-exclusive in limited cases.
>
> For example, with the latter approach: maybe when client context is
> created, it can use the default exclusive case, and certain clients
> can specify non-exclusive access (as a GUI may choose to do). Of
> course, then we get into problems with that one client that defaults
> to exclusive and tries to manipulate a working copy being
> non-exclusively accessed by that GUI. ... etc :-)
>
> If you're not talking about digging into the code yourself, then... I
> dunno. Maybe one of the Subversion vendors is willing to do spot fixes
> for a fee? Outside of that, it is tough to know when somebody will
> want to dig into the problem :-/
I rewrote some parts of the commit processing on trunk last week, which
should have a positive effect on the use cases reported in this thread.
Is it possible for somebody to see what the performance difference on NFS
is?
I'm using Windows for most of my development and testing, so I can't measure
the impact on NFS. I do see a huge improvement on Windows: The commit
harvesting time is now in the same region as the svn status time for me.
Bert
RE: svn ci performance issue with 1.7.x and nfs mounted working
copies
Posted by "Moe, Mark" <ma...@medtronic.com>.
> Well... your interest has already been noted :-) Maybe you're asking
> how you can help get the bug fixed? Volunteering, of course (as we all
> are).
...
> If you're not talking about digging into the code yourself, then... I
> dunno. Maybe one of the Subversion vendors is willing to do spot fixes
> for a fee? Outside of that, it is tough to know when somebody will
> want to dig into the problem :-/
Ok, thanks Greg. Make sense.
- Mark
[CONFIDENTIALITY AND PRIVACY NOTICE]
Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records.
To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com
Re: svn ci performance issue with 1.7.x and nfs mounted working copies
Posted by Greg Stein <gs...@gmail.com>.
Well... your interest has already been noted :-) Maybe you're asking
how you can help get the bug fixed? Volunteering, of course (as we all
are).
Philip noted a couple problems in the bug report. Focusing on how to
resolve those is likely the start of the work. I imagine at least two
approaches: ensure the same underlying wc_db instance is used in both
cases, or that we have a way to open non-exclusive in limited cases.
For example, with the latter approach: maybe when client context is
created, it can use the default exclusive case, and certain clients
can specify non-exclusive access (as a GUI may choose to do). Of
course, then we get into problems with that one client that defaults
to exclusive and tries to manipulate a working copy being
non-exclusively accessed by that GUI. ... etc :-)
If you're not talking about digging into the code yourself, then... I
dunno. Maybe one of the Subversion vendors is willing to do spot fixes
for a fee? Outside of that, it is tough to know when somebody will
want to dig into the problem :-/
Cheers,
-g
On Fri, May 4, 2012 at 12:46 PM, Moe, Mark <ma...@medtronic.com> wrote:
> Thanks Philip!
>
> Please excuse my ignorance (again), but how does the priority work? Or, how can I best show my interest in having this resolved?
>
> - Mark
>
> -----Original Message-----
> From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of Philip Martin
> Sent: Friday, May 04, 2012 4:08 AM
> To: Moe, Mark
> Cc: Daniel Shahaf; dev@subversion.apache.org; Braun, Eric
> Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working copies
>
> "Moe, Mark" <ma...@medtronic.com> writes:
>
>> Can this patch be marked as an issue or enhancement idea?
>
> I've raised http://subversion.tigris.org/issues/show_bug.cgi?id=4176
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com
>
>
> [CONFIDENTIALITY AND PRIVACY NOTICE]
>
> Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records.
>
> To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com
>
RE: svn ci performance issue with 1.7.x and nfs mounted working
copies
Posted by "Moe, Mark" <ma...@medtronic.com>.
Thanks Philip!
Please excuse my ignorance (again), but how does the priority work? Or, how can I best show my interest in having this resolved?
- Mark
-----Original Message-----
From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of Philip Martin
Sent: Friday, May 04, 2012 4:08 AM
To: Moe, Mark
Cc: Daniel Shahaf; dev@subversion.apache.org; Braun, Eric
Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working copies
"Moe, Mark" <ma...@medtronic.com> writes:
> Can this patch be marked as an issue or enhancement idea?
I've raised http://subversion.tigris.org/issues/show_bug.cgi?id=4176
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
[CONFIDENTIALITY AND PRIVACY NOTICE]
Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records.
To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com
Re: svn ci performance issue with 1.7.x and nfs mounted working copies
Posted by Philip Martin <ph...@wandisco.com>.
"Moe, Mark" <ma...@medtronic.com> writes:
> Can this patch be marked as an issue or enhancement idea?
I've raised http://subversion.tigris.org/issues/show_bug.cgi?id=4176
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
RE: svn ci performance issue with 1.7.x and nfs mounted working
copies
Posted by "Moe, Mark" <ma...@medtronic.com>.
Can this patch be marked as an issue or enhancement idea?
[I'm not sure of the process but would like to help get this implemented if possible.]
Thanks,
- Mark
-----Original Message-----
From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of Philip Martin
Sent: Tuesday, May 01, 2012 2:34 PM
To: Daniel Shahaf
Cc: Moe, Mark; dev@subversion.apache.org; Braun, Eric
Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working copies
Philip Martin <ph...@wandisco.com> writes:
> Daniel Shahaf <d....@daniel.shahaf.name> writes:
>
>> What patch are you talking about? I don't recall seeing a patch on list
>
> http://svn.haxx.se/dev/archive-2012-02/0413.shtml
>
> It executes the SQLite statement "pragma locking_mode = exclusive" after
> opening wc.db.
We can't simply commit that patch. We are a bit careless about leaving
open databases around and this causes some of the regression tests to
fail. It also affects the command line client directly, for example
"svn cp URL wc" fails when svn_wc_create_tmp_file2 opens the database.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
[CONFIDENTIALITY AND PRIVACY NOTICE]
Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records.
To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com
Re: svn ci performance issue with 1.7.x and nfs mounted working copies
Posted by Philip Martin <ph...@wandisco.com>.
Philip Martin <ph...@wandisco.com> writes:
> Daniel Shahaf <d....@daniel.shahaf.name> writes:
>
>> What patch are you talking about? I don't recall seeing a patch on list
>
> http://svn.haxx.se/dev/archive-2012-02/0413.shtml
>
> It executes the SQLite statement "pragma locking_mode = exclusive" after
> opening wc.db.
We can't simply commit that patch. We are a bit careless about leaving
open databases around and this causes some of the regression tests to
fail. It also affects the command line client directly, for example
"svn cp URL wc" fails when svn_wc_create_tmp_file2 opens the database.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: svn ci performance issue with 1.7.x and nfs mounted working copies
Posted by Philip Martin <ph...@wandisco.com>.
Daniel Shahaf <d....@daniel.shahaf.name> writes:
> What patch are you talking about? I don't recall seeing a patch on list
http://svn.haxx.se/dev/archive-2012-02/0413.shtml
It executes the SQLite statement "pragma locking_mode = exclusive" after
opening wc.db.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Re: svn ci performance issue with 1.7.x and nfs mounted working
copies
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Moe, Mark wrote on Tue, May 01, 2012 at 10:33:36 -0500:
> Yes, I tried it and it was very effective! See below:
>
> 1.6.17 1.7.4 1.7.4-patched
> NFS benchmark* 1534s 4074s 572s
> Local benchmark* 365s 162s 118s
> NFS svn co 29s 163s 18s
> Local svn co 4s 4s 3s
>
> Are there any downsides to this patch? It sounds like the only downside is a delay to simultaneous read operations for the same working-copy. Those operations are very rare for compared to the huge gains in NFS working-copy performance.
>
> Thanks for figuring out this patch!
What patch are you talking about? I don't recall seeing a patch on list
RE: svn ci performance issue with 1.7.x and nfs mounted working
copies
Posted by "Moe, Mark" <ma...@medtronic.com>.
Yes, I tried it and it was very effective! See below:
1.6.17 1.7.4 1.7.4-patched
NFS benchmark* 1534s 4074s 572s
Local benchmark* 365s 162s 118s
NFS svn co 29s 163s 18s
Local svn co 4s 4s 3s
Are there any downsides to this patch? It sounds like the only downside is a delay to simultaneous read operations for the same working-copy. Those operations are very rare for compared to the huge gains in NFS working-copy performance.
Thanks for figuring out this patch!
- Mark
* The benchmark command runs a variety of svn commands and is from here https://ctf.open.collab.net/sf/wiki/do/viewPage/projects.csvn/wiki/BenchmarkInstructions.
-----Original Message-----
From: MARTIN PHILIP [mailto:codematters@ntlworld.com] On Behalf Of Philip Martin
Sent: Tuesday, May 01, 2012 3:19 AM
To: Moe, Mark
Cc: dev@subversion.apache.org
Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working copies
Mark Moe <ma...@medtronic.com> writes:
> This is a big deal for us too. Will there be a configuration setting in an
> official svn 1.7.x version that we can use to enable the exclusive lock mode
> for SQLite? (assuming that is a valid fix for this issue)
Are you able to try a patch and tell us how effective it is?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
[CONFIDENTIALITY AND PRIVACY NOTICE]
Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records.
To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com
Re: svn ci performance issue with 1.7.x and nfs mounted working copies
Posted by Philip Martin <ph...@wandisco.com>.
Mark Moe <ma...@medtronic.com> writes:
> This is a big deal for us too. Will there be a configuration setting in an
> official svn 1.7.x version that we can use to enable the exclusive lock mode
> for SQLite? (assuming that is a valid fix for this issue)
Are you able to try a patch and tell us how effective it is?
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
RE: svn ci performance issue with 1.7.x and nfs mounted working
copies
Posted by Mark Moe <ma...@medtronic.com>.
This is a big deal for us too. Will there be a configuration setting in an
official svn 1.7.x version that we can use to enable the exclusive lock mode
for SQLite? (assuming that is a valid fix for this issue)
As it is Subversion 1.6 was slow on NFS for us and 1.7 is even worse. But,
our IT department greatly discourages local disk and makes it hard to access
from our Linux server farm. NFS disk has many benefits for us in our
enterprise environment, but svn performance is not good (especially when you
know it is so much better on local disk).
Thanks,
- Mark
Just as a comparison, the same operation with the same working copy takes 2s
in subversion 1.6.17 vs 1m11s in 1.7.2. This is a pretty big deal for us.
--
View this message in context: http://old.nabble.com/svn-ci-performance-issue-with-1.7.x-and-nfs-mounted-working-copies-tp32976250p33763319.html
Sent from the Subversion Dev mailing list archive at Nabble.com.
RE: svn ci performance issue with 1.7.x and nfs mounted working
copies
Posted by mi...@agilent.com.
Just as a comparison, the same operation with the same working copy takes 2s in subversion 1.6.17 vs 1m11s in 1.7.2. This is a pretty big deal for us.
-----Original Message-----
From: Peter Samuelson [mailto:peter@p12n.org]
Sent: Wednesday, December 14, 2011 4:48 PM
To: RYTTING,MICHAEL (A-ColSprings,ex1); dev@subversion.apache.org
Subject: Re: svn ci performance issue with 1.7.x and nfs mounted working copies
[Philip Martin]
> That will be because commit does one or more SQLite transactions
> per-node, while status has been optimised to do fewer per-directory
> transactions. The number of SQLite transactions is what dominates
> Subversion working copy performance on network disks. By running
> commit on a subtree you are restricting the number of nodes commit has
> to process and that reduces the number of SQLite transactions.
This would imply that the other way to get faster commits is to specify your filenames explicitly, instead of using the default of "any changed item under the current directory".
If this rather dramatic speed difference between 'status' and 'commit'
is really a common case, it's probably worth reimplementing 'commit' in terms of the same thing 'status' does. But I'm not deep enough in the wcng code to know if that's a reasonable course.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: svn ci performance issue with 1.7.x and nfs mounted working
copies
Posted by Peter Samuelson <pe...@p12n.org>.
[Philip Martin]
> That will be because commit does one or more SQLite transactions
> per-node, while status has been optimised to do fewer per-directory
> transactions. The number of SQLite transactions is what dominates
> Subversion working copy performance on network disks. By running
> commit on a subtree you are restricting the number of nodes commit
> has to process and that reduces the number of SQLite transactions.
This would imply that the other way to get faster commits is to specify
your filenames explicitly, instead of using the default of "any changed
item under the current directory".
If this rather dramatic speed difference between 'status' and 'commit'
is really a common case, it's probably worth reimplementing 'commit' in
terms of the same thing 'status' does. But I'm not deep enough in the
wcng code to know if that's a reasonable course.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: svn ci performance issue with 1.7.x and nfs mounted working copies
Posted by Philip Martin <ph...@wandisco.com>.
<mi...@agilent.com> writes:
> If I run "svn ci" from the root of my working copy it takes 1m11s to
> complete. However if I instead run
>
> cd <root of working copy>
> svn st
> cd subdir
> svn ci
> cd <root of working copy>
> svn up
>
> That whole set of commands takes 16s to run. The actual change I am
> committing is adding or deleting a single line of a very small script.
That will be because commit does one or more SQLite transactions
per-node, while status has been optimised to do fewer per-directory
transactions. The number of SQLite transactions is what dominates
Subversion working copy performance on network disks. By running commit
on a subtree you are restricting the number of nodes commit has to
process and that reduces the number of SQLite transactions.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com