(sorry, got a couple of these same subjects flying around, each on a
different aspect. I wanted to split them into their different aspects, but
forgot to tweak the subject line of the other two...)
Greg Stein wrote:
> Sorry for the short reply; on phone; more later.
>
> Ev2 doesn't care about text deltas. The stream passed in set_text is the
> new, desired contents. If the receiver wants to construct a delta, then
> it needs to discover a base somehow, and use that. In the RA commit
> editor case, it wants a delta for the wire, so it would take a WC
> callback at editor-construction time to get a stream of the base contents.
what? Isn't it just a revision number per file? The repos already has BASE
right there.
> The update and merge editors in the WC don't need deltas; they just use
> the new contents.
uh, what? -1.
We've got deltas lying around everywhere, don't see how 'update' should send
entire source files: We've got BASE and HEAD, should be a straightforward
delta to apply to WORKING.
Could you drive your point home for me? I don't buy it.
>
> Also note that the content stream should typically lazy-load. The
> receiver may close it immediately because it has the contents already,
> as identified by the checksum.
Sorry, don't understand what you mean. lazy-load vs. close immediately?
>
> On completion: if you don't complete something right away, then you need
> an additional signal from the driver that the node is (now) complete.
> You may also need to keep state on the incomplete node, and with no
> particular ordering, you must hold all of those states for an
> indeterminate time.
well, until the editor completes or aborts, at most. Why forbid this, given
an implementation does want to do that? (like, as we once hypothesized, a
conversion layer from editor v2 to v1 would have to?)
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2395304
Received on 2009-09-16 02:01:20 CEST