On Wed, Sep 16, 2009 at 04:27, Julian Foad <julianfoad_at_btopenworld.com> wrote:
> Greg Stein wrote:
>> 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.
>
> Whoa, you've lost me. What's the concept here? I thought the purpose of
> the editor interface was to communicate changes,
Actually, it was designed to describe a "tree delta" which could then
be applied onto a tree, to result in a different tree.
There is a subtle difference there. Editor v1 described an object,
which could then be used to effect a change. Editor v2 directly
describes the changes.
I'm not sure that this subtlety is apparent, and it may just be in my
head as a result of the mindset we had/used when designing Ev1. But
the tree delta described by Ev1 was always in terms of a set of nested
changes because of a desire to encode that tree delta as an XML
document. Thus, the notion of parents, opening batons, depth first
ordering, and all that. The intent of the API was to describe a delta
which could then be encoded into an XML doc.
Ev2 is focused on the change operations, rather than an obeyance to
serialization.
> and that it was
> designed to be serialised onto the wire for transmitting changes from
> one place to another.
Ev1 was, yes. But I believe that model to be broken. We want a series
of operations which manipulate a tree into a desired state.
> I thought it used deltas because that's normally
> the most efficient way to represent a change.
Let's be *very* clear here. "delta" has two meanings "tree delta" and
"text delta". Ev1 described tree deltas, and kind of wedged text
deltas in among that (ref: "post text-deltas" or some such
terminology; I forget). Ev2 does not talk about "delta" at all. It
performs a number of editing operations to transform one tree into a
target state.
And yes, deltas (in both senses) are the best way to represent a
change. Ev2's series of operations are analogous to a tree delta, and
have the same pattern of efficiency. Text deltas are out of its scope,
*BUT* are available when/where it makes sense for efficiency reasons
(ie. over the network).
> I note that it uses deltas to represent tree changes - "Add this node,
> delete this node," rather than "The resulting tree will be, in full: X
> X/Y X/Y/Z". (With "deltas" just meaning differences, not a particular
> encoding.)
I hope the above helps. We still have a number of specific edits, but
they are no longer packaged into a thing called "a tree delta". And
text deltas will still operate over the wire, but we no longer force
the necessity of manipulating text deltas on the rest of the code.
Let me expand that last bit some... The Editor v1 interface talked
about applying a text delta. Yet we have since learned the only real
need for a text delta is over the wire. That is the "special case"
rather than the normal case. Editor v2 simply moves text deltas to the
special case category, to be handled by libsvn_ra_* and libsvn_repos.
Everything else will just talk about the desired fulltext.
(and note that fetching files for the merge process it outside the
scope of the Editor interface; those RA requests almost always specify
a base text to be used in constructing a delta for later
reconstruction of a fulltext)
Cheers,
-g
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2395409
Received on 2009-09-16 10:56:05 CEST