[Bug] "Replace and Merge" marks the whole file as one conflicting block

[Philipp Schäfer]

What I did

A coworker saw the necessity to add the same files to both this branch and the trunk. However, he also comitted changes to the added files afterwards. I merged the content of the trunk into this branch (auto merge with dialog defaults, the branch working copy was updated beforehand). There were of course tree conflicts for the files added to the branch and the trunk. I clicked on the replace and merge option.

What I expected

I expected to see the difference between the newly replaced file and the file (as contained in the branch). Individual lines should be flagged as conflict which I would resolve manually.

What I got

The whole file was marked as a single conflicting block.

Further remarks

• I first tried to do the merge in an older version (1.12.0.28568) and then updated to the current version (1.13.1.28686) and tried again. The issue persists in the current version.
• System (Win10) and program version are both 64bit
• I used the default Tortoise diff editor

[Stefan]

The merge option is fully implemented in the svn library, so nothing in TSVN I can do about that.

But remember that a tree conflict means that the history of the file in question is 'lost'. And 'replace' means that the old content is replaced with the merged/new one. Take both of that together and you'll end up exactly with what you got: one conflicted block.

Stefan

[Nathan Hartman]

On Tuesday, April 14, 2020 at 7:19:32 AM UTC-4, Philipp Schäfer wrote:

A coworker saw the necessity to add the same files to both this branch and the trunk. However, he also comitted changes to the added files afterwards. I merged the content of the trunk into this branch (auto merge with dialog defaults, the branch working copy was updated beforehand). There were of course tree conflicts for the files added to the branch and the trunk. I clicked on the replace and merge option.

Usually in this situation, I use "merge," not "replace and merge." In fact, I just had such a tree conflict earlier today, and "merge" handled it perfectly. (I use svn's command line client, but I assume TortoiseSVN has the ordinary "merge" option.)

Hope this helps,

[Philipp Schäfer]

Thank you for your support!

The real issue is on the SVN side and I will open an issue at their tracker and ask for a change. The feature in its current state is almost unusable. There is close to zero value in getting a diff which just drops two big conflicting blocks on you. As Stefan pointed out, it is the expected behavior for a three way merge with an empty file as base.

In order to get something useful here, one would need to consider both base and first file (theirs) as the merge source and second file (mine) as the merge target. (This turns this merge effectively into a two way merge.) I will check if the merge (without replace) option shows this behavior.

@Nathan The difference between merge and "replace and merge" would sadly be a future issue in my case. The target branch is a feature branch which is not immediately merged back and closed afterwards. (In which case you could simply ignore the tree conflict while SVN does its automatic reintegration merge.) So one would get the same tree conflict for every following merge from the trunk.

Again thanks for the quick help and suggestions!