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!
Received on 2013-10-09 19:08:44 CEST