Quoting Stephen Butler <sbutler_at_elego.de>:
> Quoting Stefan Sperling <stsp_at_elego.de>:
>
>> On Thu, Aug 20, 2009 at 02:55:04PM -0700, Stephen Butler wrote:
>>> Author: sbutler
>>> Date: Thu Aug 20 14:55:04 2009
>>> New Revision: 38896
>>>
>>> Log:
>>> Report duplicate tree conflict errors in just one place (follow-up
>>> to r38872).
>>>
>>> * subversion/libsvn_client/merge.c
>>> (tree_conflict_on_add): Remove redundant error handling.
>>
>>> + /* A merge may send two separate tree-conflicts if the merge
>>> + replaces the item. This means merge will first set a tree-conflict
>>> + with an incoming "delete", and then one with an incoming "add". */
>>> + if (existing_conflict != NULL
>>> + && existing_conflict->action == svn_wc_conflict_action_delete
>>> + && conflict->action == svn_wc_conflict_action_add)
>>
>> Won't the above check also need similar treatment as done in
>> r38841 and r38848 ?
>
> Maybe we should check for (A,D) as well as (D,A).
>
> It's weird that in repos_diff.c an item is either a tree conflict
> *or* an add or a delete, etc. (in the svn_wc_notify_t_* enum).
>
> In merge.c (in the conflict struct) the tree conflict status
> is orthogonal to the action.
>
> I guess we thought a tree conflict victim didn't need any other
> notification, so it should stand alone. But since then we've
> avoided skipping the victims, at least for update. It'd be nice
> to fix the nofification to show what happened (e.g., 'R C mu').
Regarding your comment in 38848,
Failing test merge_test 132:
There is nothing that guarantees that the delete will come
before the add. If you trace the merge done in merge_test 132
and break at subversion/libsvn_client/merge.c:merge_file_added
and subversion/libsvn_client/merge.c:merge_file_deleted, you
can see that the add gets called first, then the delete (for
the file "mu").
That sounds to me like the delta editor driver is broken. Rule
number one in svn_delta.h says,
1. The producer may call open_directory, add_directory, open_file,
add_file at most once on any given directory entry. delete_entry may
be called at most once on any given directory entry and may later be
followed by add_directory or add_file on the same directory
entry. delete_entry may not be called on any directory entry after
open_directory, add_directory, open_file or add_file has been called
on that directory entry.
Is somebody calling add_file(mu), then delete_entry(mu)?
Steve
--
Stephen Butler | Software Developer
elego Software Solutions GmbH
Gustav-Meyer-Allee 25 | 13355 Berlin | Germany
fon: +49 30 2345 8696 | mobile: +49 163 25 45 015
fax: +49 30 2345 8695 | http://www.elegosoft.com
Geschäftsführer: Olaf Wagner | Sitz der Gesellschaft: Berlin
Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2385846
Received on 2009-08-21 01:31:06 CEST