One thing that you haven't mentioned explicitly that I think does help
me understand this, if I'm correct: this "set_text" call does take a
"revision" argument, which I assume (it's undocumented) is a revision
of the file which presumably both sides of the connection have the
fulltext of. The inclusion of this argument should allow the RA layer
to turn this into a delta when necessary without having to be
completely clairvoyant as to what the context it is being called in.
--dave
On Wed, Sep 16, 2009 at 1:55 AM, Greg Stein <gstein_at_gmail.com> wrote:
> 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
>
--
glasser_at_davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2395762
Received on 2009-09-17 00:55:09 CEST