[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: more editor v2

From: Greg Stein <gstein_at_gmail.com>
Date: Tue, 15 Sep 2009 15:45:16 -0400

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.

The update and merge editors in the WC don't need deltas; they just use the
new contents.

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.

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.

Cheers,
-g

On Sep 15, 2009 6:40 AM, "Neels J Hofmeyr" <neels_at_elego.de> wrote:

Hi again,

first of all, a different question to gstein -- tried to get hold of you on
IRC, but here it is via email instead:

in editor v2, how are text deltas communicated? There is a set_text() and a
set_props() ... Is it like this: if REVISION == SVN_INVALID_REVNUM then
CONTENTS is the pure text, otherwise CONTENTS is a delta relative to
REVISION? (same with set_props()?)

Which leads me to another consideration ...
 copy A to B
 edit B/file
How would this communicate across the editor? We want to edit the new
B/file, i.e. send a text delta relative to A/file_at_BASE. The set_text() only
gets a RELPATH of B/file, which is a path that technically has no revision
yet -- see my problem?
I hear that the current editor always sends a delta, against an empty file
if needed. But then the function should be called apply_text_delta()...

So, gstein, what were your intentions?

...
Now other replies:

Greg Stein wrote: >> Furthermore, if we are to add a debug/validation layer
that enforces the >
> hehe... "When", not "if" :-)

heh
let's hold a lottery draw for the great privilege and fun of writing that
validator.

>> constraints outlined by the API description, we might want to have some
>> checks against the pa...
So, say a merge tries to add a dir A/alpha, but A/alpha happens to be a file
in the target. When the callbacks send the ... meh, I keep forgetting that
it is *add*_directory(). Obviously, if A already exists, then it's already a
tree-conflict on A and A/alpha isn't of much interest.
Ok, cool. ;)

[...]

>> I would say yes, require >> paths to be in the Subversion-internal format
(separator always '/'),...
Agreed likewise.

> >> This raises a question in my head. In editor v1, each child node is >>
referred to simply by ...
The driver must be aware of whether it first moved the parent or not. I
think it's not exactly trivial, but inherent to the driver's chosen
algorithm/calling order, no general restrictions needed.

> > Typically, the root will be the working copy root, or the repository >
root. There really aren...
Maybe any subdir of the working copy root, e.g. the outermost dir of a
commit.

> > Note that an update/checkout/switch will never invoke the copy/move >
functions.
whoa, wait a minute. I agree with checkout/switch, since there's no
underlying common history involved. But update?

If user A does an 'svn copy' and commits,
then user B does an 'svn update',
surely the copy() callback should be invoked during 'update'?

Remember that copy() is the new "add_with_history" callback with a different
name. But also, IMHO 'update' should invoke move() instead of { copy();
delete(); }.

> Nodes are always added. A pristine working copy has no > knowledge of
historical copies/moves, s...
Yes, the problem that might arise is receivers having to cache things
because they can't make sane assumptions on the order of incoming data.
That's the same reason why I wanted the 'replace' stuff.

So I want to impose the restriction as below, that if an edit comes in, the
receiver doesn't ever need to cache that edit and wait until the target of
the edit arises out of a subsequent editor call:

[...]

>> "The producer must issue the editor calls in a logical sequence, so that
>> calls do not manipula...
so we've already agreed on it :)

> >> We could also add: >> >> "The editor calls must not manipulate a path
_before_ it is replace...
Neither do I, so I kept it separate. Julian, do you agree with this?
I'd like to follow this guideline:

> Until we can show a *problem* > caused by funny ordering, then let's just
leave it open.
BTW, what is the problem arising when we take away the restriction "calls
(except for the three exceptions) must complete their node before
returning"?

And I'm still waiting on a 1:1 review of the API in svn_editor.h thus far.
Maybe I'll go hide a few typos to see if anyone catches them ;)
heh, damn, version control would give them away

~Neels

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2395219
Received on 2009-09-15 21:45:47 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.