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

Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta

From: Neels Janosch Hofmeyr <neels_at_elego.de>
Date: Tue, 21 Jul 2009 04:30:53 +0200

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?



Received on 2009-07-21 04:32:38 CEST

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