RE: svn commit: r1203344 - /subversion/trunk/subversion/libsvn_delta/compat.c

> -----Original Message-----
> From: hwright_at_apache.org [mailto:hwright_at_apache.org]
> Sent: donderdag 17 november 2011 20:37
> To: commits_at_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
Received on 2011-11-18 10:06:20 CET