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

Re: editor v2 and replace

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 11 Jun 2009 09:43:35 -0400

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

Received on 2009-06-11 15:44:07 CEST

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.