Re: review: I already reviewed and edited some of the overview text. Haven't
done an exhaustive review yet.
Re: update and copy: the resulting WC state should be the same, whether you
use checkout or update. So if checkout does not use copy(), then why should
update? I assume you're trying to optimize, rather than a correctness
issue...
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=2395223
Received on 2009-09-15 21:58:30 CEST