Thanks for the explanation Stefan. Glad svn is working properly :-)
-----Original Message-----
From: Stefan Sperling [mailto:s...@elego.de]
Sent: 09 September 2013 15:55
To: James French
Cc: users@subversion.apache.org
Subject: Re: Reverse merge with 1.8.3 yielded tree conflicts
On Mon, Sep 09, 2013 at 02:37:05PM +0100, James French wrote:
> Hi,
>
> I got a report today of svn 1.8.3 (tortoise 1.8.2) producing tree conflicts
> when a sync up merge was reverted. I ran the merge again with 1.8.3 to
> confirm the issue and again using 1.7.8 command line (which worked). See the
> status reports below (a bit hacked manually to remove some sensitive stuff
> but hopefully there's enough to get an idea). Looks like a regression.
>
No, this is a feature, not a regression.
It is listed in CHANGES as:
* tree conflicts on directories detected better during merges (issue #3150)
Short story is that 1.7 was deleting subtrees during merges without considering
the contents of what was being deleted. Whereas 1.8 flags a tree conflict if
the subtree being deleted during a merge differs from what the commit being
merged was deleting on the merge source branch.
This allows you to verify whether the deletion of that subtree is in fact
desired within the context of the merge target.
In Subversion 1.7, users who were concerned about that had to manually verify
every deleted subtree before committing the result of a merge.
The purpose of these new tree conflicts flagged by 1.8 is to point out the
deleted subtrees which might require such manual verification.
In your case, you seem to be fine with the deletion of the affected subtrees.
So you can run this to resolve the conflict for each subtree, for example:
svn resolve --accept working SceneInteraction # clear conflict marker
svn rm SceneInteraction # delete what should be deleted
In the future, we hope to improve the UI to better guide users during
interactive resolution of these conflicts.
