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

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

From: Stephen Butler <sbutler_at_elego.de>
Date: Fri, 21 Aug 2009 01:29:50 +0200

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)?


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
Received on 2009-08-21 01:31:06 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.