> -----Original Message-----
> From: justin.erenkrantz_at_gmail.com [mailto:justin.erenkrantz_at_gmail.com] On
> Behalf Of Justin Erenkrantz
> Sent: zaterdag 19 mei 2012 16:02
> To: Subversion Development
> Subject: Ev2 question regarding properties?
>
> Ev2 folks,
>
> I've been thinking a little bit about how to optimize the PROPFIND
> requests in ra_serf. The core issue we had with Ev1 was that we had
> to delay setting any of the properties until we had the file handle
> open - this is why, way back in 2006, I just coded it to have a
> parallel HTTP request per entry and had to do tracking to ensure we
> did the right thing about ordering of the HTTP requests/responses.
>
> Will Ev2 offer some lightweight way to set properties on a bunch of
> local WC paths? Do the textbases already need to be present? (I'm
> thinking here about how we would handle EOL properties.) Will we need
> to keep the WC file handle open once we set the properties? ISTR that
> a Ev1 characteristic was that you can't re-open a file multiple times
> in an editor drive. And, we couldn't keep too many file handles open
> or we would exhaust ulimits and such. Hence, thinking back on it now,
> the reason we ended up where we did with ra_serf wasn't as much about
> HTTP or serf - but more about the original editor API.
No, the idea of editor v2 is that we update a node in a single atomic
operation.
If we would update just the properties or just the text, we have a node that
is neither at its old revision, nor at its new revision. And that is
something that we try to avoid in editor v2.
E.g. for directories we update the list of children and the properties in
one operation, to avoid the old 'incomplete' state of editor v1.
> I'm guessing that if Ev2 doesn't cleanly support allowing properties
> to be set completely independently from the textbases, we may want to
> consider modifying Ev2 to support this in order to allow ra_serf to
> batch up properties in one go or at least batched per-directory.
Editor v2 was explicitly designed to *not* allow this :)
And I leave answering the rest to those that are actively working on the
editor.
(Which I'm not. I'm still not sure that editor v2 will really gain us enough
performance, given that the current update process handles a lot of
obstruction and conflict cases on opening parent directories. We'll see if
that scales to per node updates.)
Bert
Received on 2012-05-19 16:10:40 CEST