Merging trunk causes false-positive conflicts

[Filip Slavov via users]

Hello,

I believe SVN sometimes gives false-positive tree conflicts on merging. This is best explained with an example. Here are repo steps:

1. Create trunk
2. Add and commit two images & txt file: "Assets/Hi.png", "Assets/Hi2.png", "Assets/Main.txt".
   
3. Create branch, DLC1.
4. In Trunk: Edit both images - invert their colors. Add some line in the text file. Commit changes.
   
5. In DLC1: edit "Main.txt", avoid conflicts with the trunk. Commit.
6. In DLC1: merge everything from trunk.
7. In Trunk: invert "Hi.png", change "Main.txt" some more and commit. DON'T change "Hi2.png"
8. In Trunk: merge changes from DLC1.
9. In DLC1: delete "Hi2.png" and commit.
10. In DLC1: merge changes from trunk.

On step 10 I expect everything to merge without issues, but it results on tree-conflict on "Hi2.png" saying: "local missing or deleted or moved away, incoming file edit upon merge"

But there are no changes to "Hi2.png" incoming with this merge - those were merged way back on step 6.

I'm describing steps instead of commands as I'm actually using TortoiseSVN. Here is how it looks there:

And the conflict:

When merging in TortoiseSVN, we always leave the range field empty which results in reintegration/automatic merge. This way we hope to have less tree conflicts with itself in the future.

So, is merging all revisions wrong? Why can't SVN figure out that this file doesn't have new incoming changes, so there is no need for tree-conflict? The same way the text file is automatically merged and doesn't conflict with itself. This has caused us a lot of pain when doing svn branches - long-lived branches tend to conflict without a good reason. Resolving those conflicts is hard as users have to do it one by one, which is painful and error-prone. No way to mass-resolve tree-conflicts :(

SVN version: version 1.9.3-SlikSvn (SlikSvn/1.9.3)   compiled Dec 15 2015, 12:13:34 on x86_64-microsoft-windows6.2.9200

Using up-to-date Windows 10.

Thanks,

Filip Slavov

[Daniel Sahlberg]

Thank you for your detailed description! I think I've reproduced your description in the following script on the command line using Subversion 1.14.2. To be able to "edit" on the command line, I've made a few pre-edited files and I'm just copying them into place. The script should be easy enough to update to run under Unix.

[[[

:: Step 1: Create trunk
svnadmin create repo_merge
svn co file:///c:/devel/temp/repo_merge wc_merge
cd wc_merge
mkdir trunk
svn add trunk
mkdir branches
svn add branches
svn ci . -m "Step1: Create trunk"

:: Step 2: Add & commit two images & txt file
mkdir trunk\Assets
copy ..\main.txt trunk\Assets
copy ..\black.png trunk\Assets\Hi.png
copy ..\grey.png trunk\Assets\Hi2.png
svn add trunk\Assets
svn ci trunk\Assets -m "Step 2: Add assets in trunk"
svn up

:: Step 3: Create a branch
svn copy file:///c:/devel/temp/repo_merge/trunk file:///c:/devel/temp/repo_merge/branches/DLC1 -m "Step 3: Create branch DLC1"
svn up

:: Step 4: In trunk: Edit both images and add some link in the text file
copy ..\main2.txt trunk\Assets\main.txt
copy ..\maroon.png trunk\Assets\Hi.png
copy ..\red.png trunk\Assets\Hi2.png
svn ci trunk\Assets -m "Step 4: Modify assets in trunk"
svn up

:: Step 5: Edit text in DLC1, avoid conflict with trunk
copy ..\main3.txt branches\DLC1\Assets\main.txt
svn ci branches\DLC1 -m "Step 5: Edit text in DLC1 without causing conflict"
svn up

:: Step 6: In DLC1, merge from trunk
svn merge ^^/trunk branches\DLC1
svn ci branches\DLC1 -m "Step 6: Merge trunk to DLC1"
svn up

:: Step 7: In trunk: Change Hi.png and Main.txt (but leave Hi2.png alone)
copy ..\main4.txt trunk\Assets\main.txt
copy ..\orange.png trunk\Assets\Hi.png
svn ci -m "Step 7: Change hi.png and main.txt"
svn up

:: Step 8: In trunk, merge from DLC1
svn merge ^^/branches/DLC1 trunk
svn ci -m "Step 8: Merge DLC1 to trunk"
svn up

:: Step 9: In DLC1, delete hi2.png
svn del Branches\DLC1\Assets\Hi2.png
svn ci -m "Step 9: Delete Hi2.png from DLC1"

:: Step 10: In DLC1, merge from trunk
svn merge ^^/trunk branches\DLC1
:: Boom,. tree conflict

]]]

The error message is:

[[[

C:\Devel\temp\wc_merge>svn merge ^^/trunk branches\DLC1
--- Merging differences between repository URLs into 'branches\DLC1':
U    branches\DLC1\Assets\Hi.png
   C branches\DLC1\Assets\Hi2.png
U    branches\DLC1\Assets\main.txt
--- Recording mergeinfo for merge between repository URLs into 'branches\DLC1':
 U   branches\DLC1
Summary of conflicts:
  Tree conflicts: 1
Searching tree conflict details for 'branches\DLC1\Assets\Hi2.png' in repository:
Checking r9... done
Tree conflict on 'branches\DLC1\Assets\Hi2.png':
Changes destined for a file arrived via the following revisions during merge of
'^/trunk/Assets/Hi2.png:7-9':
 (no revisions found)
No such file or directory was found in the merge target working copy.
'^/branches/DLC1/Assets/Hi2.png' was deleted in r9 by danie.

Subversion is not smart enough to resolve this tree conflict automatically!
See 'svn help resolve' for more information.

Select: (p) Postpone, (r) Mark as resolved, (h) Help, (q) Quit resolution: p
Summary of conflicts:
  Tree conflicts: 1
]]]

The problem only occurs when merging without a specified revision. Cherry-picking each of revisions 6 to 9 or merge them all together (-r5:9) works, confusingly even -r1:HEAD works fine(!?!):

[[[

C:\Devel\temp\wc_merge>svn merge ^^/trunk branches\DLC1 -r1:HEAD
--- Merging r6 through r9 into 'branches\DLC1':
U    branches\DLC1\Assets\Hi.png
U    branches\DLC1\Assets\main.txt
--- Recording mergeinfo for merge of r6 through r9 into 'branches\DLC1':
 U   branches\DLC1

]]]

The same trick can be applied in TortoiseSVN, specifying the revision range 1-HEAD in the input box.

 

SVN version: version 1.9.3-SlikSvn (SlikSvn/1.9.3)   compiled Dec 15 2015, 12:13:34 on x86_64-microsoft-windows6.2.9200

Using up-to-date Windows 10.

Please note that Subversion 1.14 is the only version currently in support, so if possible consider upgrading as this will only be fixed in the latest version. I'm a bit confused since you mention SlikSvn while clearly screenshooting TortoiseSVN, anyhow both have 1.14 version available for download.

Kind regards,

Daniel Sahlberg

[Filip Slavov via users]

Interesting, 1-HEAD works. So I guess empty range is not the same. So is this a bug or a feature (intended behaviour)? :D I can live with this solution for now.

About the svn version: that's my bad. I use TortoiseSVN, but for the version I typed "svn --version" and thanks to you I discovered I have installed SlikSVN from 2015, don't know why :D I removed it and am using the latest version of TortoiseSVN, which comes with this: svn, version 1.14.2 (r1899510)  compiled Sep 24 2022, 10:21:16 on x86-microsoft-windows

Result is the same with the new version.

[Filip Slavov via users]

So, I tried using 1-HEAD in real environment and it did not yield results - there were different conflicting files compared to no-revision merge.

Generally, does SVN support long-standing feature branches with multiple back & forth merges? I notice that all conflicts are with moved/deleted files coming from the feature branch itself - if delete goes to the trunk then back to the feature branch it randomly conflicts.

Any advice on how to deal with such tree-conflicts?

Thanks