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.
