Julian Foad wrote:
>> The driver is required to use add() with REPLACES_REV instead of a separate
>> delete() call before this add(). Receivers of this callback in general are
>> not required to support a separate delete() call for a 'replace'.
>
> I think it would be clearer to state the editor requirements separately
> from the usage recommendations. (This last paragraph and the following
> one seem to mix the two.)
>
>> If you intend to implement a separate delete() call when driving this
>> editor, make sure you really have to and put up "big red signs" in the
>> documentation of your driver. Be aware that, in general, the driver should
>> do all of the (possibly hard) work of combining a delete() with an add() to
>> form an atomic replace, taking that burden off the various receivers. So if
>> you write a driver that doesn't do that, you have to make sure that all your
>> receivers (preferably very few) can handle a non-atomic replace.
>> Furthermore, a delete() call should occur always before, never after an
>> add() call for the same node.
>> ]]]
Yes, you're right.
Where is the line between editor requirements and usage recommendations?
Maybe you can help to choose a side... Or are these sides chosen by
individual implementations anyway?
I am more for forcing an atomic replace. I would rather remove the loophole
that says "well, but if you must, just issue separate calls". I'd personally
not mind if some parts of the code send separate calls, but I want e.g. the
merge callback receivers to be certain that they will *not* receive separate
calls *ever*.
How about we choose the stricter comment, but we let people use it
differently if they must without saying so now?
"The receiver is not required to handle a separate delete() and add() call
on the same path.
The driver must always combine any delete() that is followed by an add()
to a single add()-with-REPLACES_REV."
Some Qs:
- is it ok to disallow multiple add() and delete() calls on the same path,
in principle?
e.g. during merge, there are only the two sides, merge-left
and merge-right. A replace means that both exist but are "unrelated". So
a merge will never need to send more than one (delete, add) tuple.
Usually it's either *one* delete or *one* add. The (add, delete) tuple
simply cancels out, nothing being sent.
But are there cases where we also send all the steps in-between? Then we
could allow this: add(), add(REPLACES_REV), add(REPLACES_REV), delete().
But *are there*?
- is it necessary to disallow multiple add() and delete() calls on the same
path, to make the atomic replace useful?
e.g. during merge, the receiver needs to cache all delete()s and match
with add()s, carrying out the leftovers during dir_close(). And merge
is not the only one in need of this quirky code construct.
I want to eradicate this madness -- I'd love to force atomic replaces
on everyone, so the receivers are entirely relieved of this quirkiness.
Will allowing both separate and atomic replace calls defy my plan by
actually adding more code to the receivers?
- is there a case where separate calls have a different meaning than an
atomic replace?
e.g. for merge, it doesn't matter whether the nodes are "related".
I can't think of any case where we'd want to highlight that the node was
deleted and later re-added with the same history, or something. Right?
~Neels
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2372796
Received on 2009-07-21 04:32:38 CEST