RE: svn commit: r1203344 - /subversion/trunk/subversion/libsvn_delta/compat.c
From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 18 Nov 2011 10:05:42 +0100
> -----Original Message-----
How did this happen? Did we miss this in the design?
The update editor uses the target revision in every changing callback (new revision) and some of the other callbacks (tree conflicts, etc.). When a node is changed by an update it is brought in the state of that revision, so that revision should be well known. Especially because we bump the revision of *all* nodes that aren't touched by an update after the update.
Seeing your progress:
The number of added callbacks that weren't in the initial plan to retrieve information from the working copy are making me nervous. Every single call in to wc.db has a non-zero cost to obtain and release the read lock.
I had to remove quite a few db calls to make 1.7 perform as good on updating a node as it does now and it could really use more improvement.
"If our editor v2 would perform 3* slower than the current update process on the currently installed servers, it isn't going to work for our users."
Of course our future performance is just guessing now, but maybe we should verify if our design still covers our needs.
This is an archived mail posted to the Subversion Dev mailing list.