Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (athena.apache.org: local policy)
Date: Mon, 4 Feb 2013 20:00:51 +0100
From: Stefan Sperling <stsp@elego.de>
To: Philip Martin <philip.martin@wandisco.com>
Cc: dev@subversion.apache.org
Subject: Re: svn commit: r1442177 -
 /subversion/trunk/subversion/tests/libsvn_wc/op-depth-test.c
Message-ID: <20130204190051.GG32109@byrne.stsp.name>
Mail-Followup-To: Philip Martin <philip.martin@wandisco.com>,
	dev@subversion.apache.org
References: <20130204170016.A1F142388ABA@eris.apache.org>
 <87sj5cuh5j.fsf@ntlworld.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87sj5cuh5j.fsf@ntlworld.com>
User-Agent: Mutt/1.5.21 (2010-09-15)

On Mon, Feb 04, 2013 at 05:23:52PM +0000, Philip Martin wrote:
> The test reaches a state with a delete-edit tree-conflict on X/B/C as a
> result of the update following some of the moves.  This conflict has to
> be resolved to state 'working' which will remove the tree-conflict on
> X/B/C and raise a move-edit tree-conflict on X/B/C/D/E.  Resolving that
> new move-edit tree-conflict to state 'mine-conflict' will update E2 and
> allow the test to pass.  However when the resolver is invoked on X/B/C
> it automatically proceeds to resolve the new tree-conflict on X/B/C/D/E
> and that causes the test to fail.
> 
> Having the resolver raise new tree-conflicts is new behaviour.  Having
> the resolver code use the status walker is also new behaviour.  To make
> this work I need the resolver to avoid resolving the newly raised
> tree-conflict but I'm not sure how best to do this.  Sometimes resolving
> newly raised tree-conflicts is helpful to the user.

As far as I can see the only problem here is that you'd like to resolve
the conflict on 'X/B/C' to 'choose merged', but because the test ends
up passing depth infinity to svn_wc__resolve_conflicts() it also
resolves 'X/B/C/D/E' to 'choose_merged', while you want to resolve
that node to 'mine_conflict' instead.

I haven't tried, but you could probably change the test to pass a
depth != infinity to svn_wc__resolve_conflicts() when resolving
on 'X/B/C'. Would that help?