RE: tree conflict in merge after deleting and re-adding files

[Bob Archer]

> Hi All,
> 
> TortoiseSVN 1.6.16, Build 21511 - 64 Bit , 2011/06/01 19:00:35 Subversion
> 1.6.17, apr 1.3.12 apr-utils 1.3.12 neon 0.29.6 OpenSSL 1.0.0d 8 Feb 2011 zlib
> 1.2.5 We have a problem. We have a trunk and a branch, and wanted to merge
> changes from branch to trunk. Due to some heavier file-conflicts I'we deleted
> foo.txt in trunk in SVN, copied it from branch and added again. Now I now it
> was a mistake.
> Now if we try to make merge, we always get tree conflict on foo.txt - its
> contents are already identical in trunk and branch. I know that the 
> discontinuity
> in foo.txt for a range of revisions, so the lack of ancestry causes that.
> 
> foo.txt was already deleted and re-added in branch by other developer.
> We have already tried a range of solutions found on the web, but no success. 
> Is
> there a way to tell SVN to forget this tree conflict thing for ever?
> thank you in advance.
> Best regards: Balázs

If you do a merge, and resolve the tree conflict, and then commit the merge... 
subsequent merges will no longer try to merge in the delete change and you 
shouldn't see further issues.

If you keep seeing the same conflict, it sounds like you aren't committing the 
merge-info that is set on the project root. (you should always merge from the 
project root).

BOb

Re: tree conflict in merge after deleting and re-adding files

[Stefan Sperling]

On Wed, Oct 09, 2013 at 06:50:32PM +0200, Balázs Bámer wrote:
> Hi All,
> 
> TortoiseSVN 1.6.16, Build 21511 - 64 Bit , 2011/06/01 19:00:35
> Subversion 1.6.17,
> apr 1.3.12
> apr-utils 1.3.12
> neon 0.29.6
> OpenSSL 1.0.0d 8 Feb 2011
> zlib 1.2.5
> 
> We have a problem. We have a trunk and a branch, and wanted to merge
> changes from branch to trunk. Due to some heavier file-conflicts I'we
> deleted foo.txt in trunk in SVN, copied it from branch and added again. Now
> I now it was a mistake.
> 
> Now if we try to make merge, we always get tree conflict on foo.txt - its
> contents are already identical in trunk and branch. I know that the
> discontinuity in foo.txt for a range of revisions, so the lack of ancestry
> causes that.
> 
> foo.txt was already deleted and re-added in branch by other developer.
> 
> We have already tried a range of solutions found on the web, but no
> success. Is there a way to tell SVN to forget this tree conflict thing for
> ever?
> 
> thank you in advance.
> 
> Best regards: Balázs

You've created a new line of history for the name foo.txt.

Delete the new foo.txt, and copy the old foo.txt (from before when
you first deleted it) to the same path. Then change foo.txt contents
to match the contents of the new foo.txt (this can be done via 'svn
merge' but also with an editor). Commit.

After that, now you'll need to resolve a tree conflict once more when
you merge the addition of the "old-new" foo.txt to the branch. Accept
the incoming replacement (there won't be a menu item to do this, you'll
need to copy the file from the other branch into the working copy yourself
and mark the conflict resolved with svn resolve --accept=working).
Then edit the replaced file so it has the proepr contents for the
branch.

Not easy, and certainly something where Subversion could do a lot better
with helping the user jump through hoops. But it's not impossible
either.

For the future, keep in mind that Subversion applies tree changes first,
and content changes second. Always. If you are replacing a file, rather
than replacing its contents, Subversion takes your word for it and does
that.

Note that some cases where a replacement happened accidentally (such as
svn move A B; svn move B A;) have been fixed in Subversion 1.8.
You should strongly consider an upgrade from 1.6!