Login | Register
My pages Projects Community openCollabNet

Discussions > dev [DISABLED] > Re: svn commit: r38896 - trunk/subversion/libsvn_client

subversion
Discussion topic

Back to topic list

Re: svn commit: r38896 - trunk/subversion/libsvn_client

Author sbutler
Full name Stephen Butler
Date 2009-08-20 16:29:52 PDT
Message Quoting Stephen Butler <sbutler at elego dot de>:

> Quoting Stefan Sperling <stsp at elego dot 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_cl​ient/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_cl​ient/merge.c:merge_f​ile_added
   and subversion/libsvn_cl​ient/merge.c:merge_f​ile_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

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

Messages

Show all messages in topic

Re: svn commit: r38896 - trunk/subversion/libsvn_client stsp Stefan Sperling 2009-08-20 15:35:49 PDT
     Re: svn commit: r38896 - trunk/subversion/libsvn_client sbutler Stephen Butler 2009-08-20 16:21:57 PDT
         Re: svn commit: r38896 - trunk/subversion/libsvn_client sbutler Stephen Butler 2009-08-20 16:29:52 PDT
             Re: svn commit: r38896 - trunk/subversion/libsvn_client stsp Stefan Sperling 2009-08-20 17:04:17 PDT
                 Re: svn commit: r38896 - trunk/subversion/libsvn_client stsp Stefan Sperling 2009-08-21 02:08:23 PDT
         Re: svn commit: r38896 - trunk/subversion/libsvn_client neels Neels Janosch Hofmeyr 2009-08-21 17:54:47 PDT
Messages per page: