Greg Stein wrote:
> Hmm. I figured that with the "add follows" flag, then you could know
> to avoid dual-notifications, and just wait for the add. But yah...
> then you'd need to remember (at add time) that a delete had happened.
> More cross-call state.
>
> Adding a flag to the add calls should work. Tho I hate the "replace"
> terminology. Maybe "overwrite=TRUE" is better? (and, of course,
Hm, I much prefer the "replace" terminology. The item was removed, and
another one added in its place. Replace, right?
If I read it the first time, "overwrite" would probably not convey its real
meaning to me, I guess I would associate it with an internal helper thing...
but maybe that's just me.
> failure if you're trying to overwrite, and nothing is there)
>
> Bikeshed. But yah. Extending the add calls sounds better. Thanks!
Yes, that's very nice, thanks guys!
~Neels
>
> Cheers,
> -g
>
> On Thu, Jun 11, 2009 at 15:43, C. Michael Pilato<cmpilato_at_collab.net> wrote:
>> You'll still got two editor calls, though. Could we instead just add an
>> "is_replace" flag to the add operation? (Drivers would not call the delete
>> in that situation.)
>>
>> Greg Stein wrote:
>>> Yeah... I can see how the separation makes things more difficult.
>>>
>>> Rather than a replace, with various node kind magic... how about a
>>> flag on the remove() operation which says "add follows" ? That should
>>> keep things much simpler, and we wouldn't need a bunch of variants or
>>> generic args.
>>>
>>> Cheers,
>>> -g
>>>
>>> On Thu, Jun 11, 2009 at 03:23, Neels J Hofmeyr<neels_at_elego.de> wrote:
>>>> Hi Greg,
>>>>
>>>> IMHO it would be nice to have an svn_editor_cb_replace_t in editor v2.
>>>>
>>>> I'm currently faced with a merge that replaces an item. The item is first
>>>> deleted and later added in a given merge range. Thus, merge first calls
>>>> file_deleted() and then file_added() (current "diff editor" callbacks).
>>>>
>>>> That's a little awkward for
>>>>
>>>> - displaying "R" instead of two lines "D" and "A" (diff --summarize?)
>>>>
>>>> - making sense of a tree conflict. I'm currently fixing exactly this case,
>>>> where a merge replaces a file on top of a locally modified file. The current
>>>> code tries to create two tree-conflicts on the same item and fails.
>>>>
>>>> It would need generic arguments for mixed node kinds...
>>>> If you agree, I'll be glad to add that, so you can review it to shreds ;)
>>>>
>>>> ~Neels
>>>>
>>>>
>>>>
>>> ------------------------------------------------------
>>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2361206
>>
>> --
>> C. Michael Pilato <cmpilato_at_collab.net>
>> CollabNet <> www.collab.net <> Distributed Development On Demand
>>
>>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2361477
Received on 2009-06-12 01:46:08 CEST