Login | Register
My pages Projects Community openCollabNet

Discussions > dev [DISABLED] > Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta

subversion
Discussion topic

Back to topic list

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

Author neels
Full name Neels Janosch Hofmeyr
Date 2009-07-20 19:31:53 PDT
Message 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
Attachments

« Previous message in topic | 6 of 22 | Next message in topic »

Messages

Show all messages in topic

Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta julianfoad Julian Foad 2009-07-10 03:35:24 PDT
     Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta neels Neels Janosch Hofmeyr 2009-07-11 15:34:49 PDT
         Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta julianfoad Julian Foad 2009-07-11 17:04:55 PDT
             Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta neels Neels Janosch Hofmeyr 2009-07-18 14:20:07 PDT
                 Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta julianfoad Julian Foad 2009-07-19 10:53:47 PDT
                     Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta neels Neels Janosch Hofmeyr 2009-07-20 19:31:53 PDT
                         Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta stsp Stefan Sperling 2009-07-21 04:44:44 PDT
                             operation based merging -- was: Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta neels Neels Janosch Hofmeyr 2009-07-21 06:36:04 PDT
                                 Re: operation based merging -- was: Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta stsp Stefan Sperling 2009-07-21 07:44:55 PDT
                                     Re: operation based merging -- was: Re: svn commit: r38394 - in trunk/subversion: include libsvn_delta gavinbaumanis Gavin Baumanis 2009-07-21 16:33:05 PDT
                         Defining atomic "replace" [was: svn commit: r38394 - in trunk/subversion: include libsvn_delta] julianfoad Julian Foad 2009-07-28 03:28:37 PDT
                             Re: Defining atomic "replace" neels Neels Janosch Hofmeyr 2009-08-11 11:53:36 PDT
                                 Re: Defining atomic "replace" gstein Greg Stein 2009-08-11 13:04:12 PDT
                                     Re: Defining atomic "replace" Bill Tutt <bill dot tutt at gmail dot com> Bill Tutt <bill dot tutt at gmail dot com> 2009-08-13 07:41:32 PDT
                                         Re: Defining atomic "replace" julianfoad Julian Foad 2009-08-13 16:24:48 PDT
                                             Re: Defining atomic "replace" Bill Tutt <bill dot tutt at gmail dot com> Bill Tutt <bill dot tutt at gmail dot com> 2009-08-14 11:12:04 PDT
                                 Re: Defining atomic "replace" julianfoad Julian Foad 2009-08-11 16:27:08 PDT
                                     Re: Defining atomic "replace" julianfoad Julian Foad 2009-08-11 16:31:17 PDT
                                     Re: Defining atomic "replace" neels Neels Janosch Hofmeyr 2009-08-12 10:51:43 PDT
                                     no-op-copy -- was: Re: Defining atomic "replace" neels Neels Janosch Hofmeyr 2009-08-12 12:00:55 PDT
                                         Re: no-op-copy -- was: Re: Defining atomic "replace" julianfoad Julian Foad 2009-08-12 17:03:11 PDT
                                             Re: no-op-copy -- was: Re: Defining atomic "replace" neels Neels Janosch Hofmeyr 2009-08-12 17:53:07 PDT
Messages per page: