On Tue, Oct 09, 2012 at 09:10:41PM +0200, Martin Bischoff wrote: > Thanks a lot for the detailed information. Please see below for some > additional questions.
Sure. > > The incoming delete of A conflicts with the local delete of A. > > This happened because both sides (trunk, and branch) decided to > > rename A to B, and Subversion cannot yet tell the difference > > between a normal deletion and a deletion that happens as part > > of a move (which sucks, and we're trying to fix this, but that's > > a separate discussion). In this particular case, deleting A is the > > > > Will the (hopefully soon-to-be-released) version 1.8 already contain some > improvements in that area? Not for incoming moves, no. Maybe for moves which exist as local changes in the working copy. But that helps mostly during updates, not so much during merges. > Instead of merging revision N and resolving the conflicts, would a > record-only merge of revision N give the same result? Yes, except that record-only merges will update all subtree mergeinfo within the merge target, if any exists. > Is the same procedure required when renaming files instead of folders, or > does this issue only happen when renaming folders? It happens with files, too, and the workaround should be pretty much the same.