That revision argument is present to flag errors.
"Change r1 of FILE to 'hello'" -> ERROR: FILE was edited in r2
It's there for out-of-dateness checks, just like all the revision
argument in the other APIs. "move r4 of DIR to ..." "ERROR: DIR was
deleted in r7" ... IOW, it makes explicit the Driver's assumption of
what is being operated upon.
Cheers,
-g
On Wed, Sep 16, 2009 at 18:54, David Glasser <glasser_at_davidglasser.net> wrote:
> 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=2395784
Received on 2009-09-17 03:48:20 CEST