Re: editor v2 and replace

Hi again,

how about making that "is_replace" flag something like an svn_node_kind_t?
Then the receiver already knows what kind of node it is supposed to be
replacing and doesn't need to figure that out painfully.

A clean add would simply pass svn_node_none.

I don't know what svn_node_unknown would represent, though, and it seems
we'd also need to represent a "symlink" and an "absent" node kind... In fact
I don't grok the "add_absent" callback, and how symlinks are treated.

Are we going to extend svn_node_kind_t? What else would make sense?

A pseudo-diff to illustrate:
[[[
 svn_editor_add_directory(svn_editor_t *editor,
                          const char *relpath,
                          const apr_array_header_t *children,
- apr_hash_t *props);
+ apr_hash_t *props,
+ svn_node_kind_t replaces);

 svn_error_t *
 svn_editor_add_file(svn_editor_t *editor,
                     const char *relpath,
- apr_hash_t *props);
+ apr_hash_t *props,
+ svn_node_kind_t replaces);

 svn_error_t *
 svn_editor_add_symlink(svn_editor_t *editor,
                        const char *relpath,
                        const char *target,
- apr_hash_t *props);
+ apr_hash_t *props,
+ svn_node_kind_t replaces);

 svn_error_t *
 svn_editor_add_absent(svn_editor_t *editor,
                       const char *relpath,
- svn_node_kind_t kind);
+ svn_node_kind_t kind,
+ svn_node_kind_t replaces);

]]]

Thanks some more,
~Neels

Neels Janosch Hofmeyr wrote:
> 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

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2361480