> -----Original Message-----
> From: hwri...@apache.org [mailto:hwri...@apache.org]
> Sent: donderdag 17 november 2011 20:37
> To: comm...@subversion.apache.org
> Subject: svn commit: r1203344 -
> /subversion/trunk/subversion/libsvn_delta/compat.c
>
> Author: hwright
> Date: Thu Nov 17 19:37:29 2011
> New Revision: 1203344
>
> URL: http://svn.apache.org/viewvc?rev=1203344&view=rev
> Log:
> Ev2 shims: Properly pass around the target rev value. Since Ev2 doesn't have
> this concept (similar to "start of edit") we have to pass this value through
> a secondary callback. Ugly.
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:
How well is editor v2 going to perform in the for the next few years after
release common scenarios where either a client or the repository is not going
to be using editor v2.
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.
Bert
