"Cannot merge into mixed-revision working copy" TortoiseSVN 1.14.1

[Kieren]

Hey,

I'm getting this error a lot when merging after the latest TortoiseSVN update and having to update each time then re-merge. This can happen on the same checkout minutes apart after just merging to it. Is there an easy way for me to fix this?

I've seen comments elsewhere of using "--allow-mixed-revisions" but haven't been able to get this to work when adding it to a TortoiseProc shortcut, nor find a setting for this (using the Windows interface).

As far as I can tell they aren't mixed checkouts, have switched them to make sure, updated with Omit Externals, tried re-checking out (happens on different/all branches I have checked out anyway).

Help would be appreciated, otherwise I may try go back to the previous TortoiseSVN version as it's only started doing this after updating to:

TortoiseSVN 1.14.1, Build 29085 - 64 Bit , 2021/02/09 16:17:02

Cheers

[Dean Bailes]

I'm having exactly the same issue since updating to 1.14.1 2021/02/09

Really slowing down merging multiple changes :-( 

[Dean Bailes]

Just to confirm, I've gone back and re-installed 1.14.0 again and now my merging is back to normal again so it's definitely something in 1.14.1.

On Tuesday, 23 February 2021 at 21:09:32 UTC Kieren wrote:

[Stefan]

That was changed because merging into a mixed-rev wc can lead to wrong merges. See here:

https://groups.google.com/g/tortoisesvn/c/cplTU-e_IU0/m/aW6M6kTmAwAJ

[DutchPavlo]

It is very nerving. We oft merging a lot of revisions at one time from development to our quality trunk. The merges have to been done seperate to insure the possibility too take them back or merge them too trunks of clients. After each merge you have too update the repository. Why is this not done by the merge?

[Daniel Sahlberg]

fredag 12 mars 2021 kl. 11:31:30 UTC+1 skrev DutchPavlo:

It is very nerving. We oft merging a lot of revisions at one time from development to our quality trunk. The merges have to been done seperate to insure the possibility too take them back or merge them too trunks of clients. After each merge you have too update the repository. Why is this not done by the merge?

This was a design decision by the Subversion project (back in 2000-2001 when Subversion was created) that you can have "mixed revison working copies". Some background can be found in the SVN book:

http://svnbook.red-bean.com/en/1.7/svn.basic.in-action.html#svn.basic.in-action.mixedrevs

I've tested this out and I get the error message but I also  get a helper diaog "Shall I update the working copy and retry?". If I run the update the merge will be retried and it succeeds for me. So I think TortoiseSVN is doing what it can to help.

If you really don't want mixed revision WCs then you can probably create a post-commit hook script that do svn update in the wc. YMMV.

Kind regards,

Daniel Sahlberg

[Kieren]

One of the main problems where this affects me is having a large number of people using a checkout, if there's something I need to revert I used to be able to just update those specific files then revert and commit to the main repo folder quite quickly, but because of this error I now have to fully update the folder adding quite a bit of time to getting sorted and those reverts out fast.

Just a bit surprised there isn't an option to stop or ignore this error from coming up if we want to choose not to worry this for a folder, as it doesn't mind after we update it anyway - would this be easy to add? It just seems a bit frustrating to get this error every time I go to commit now, even if there's nothing new in an update.

Cheers,

Kieren

[Dimas SC]

It's very frustrating that after selecting manually some commits you try to merge and this error appears and you must start from 0! A waste of time. Please add some way to avoid that. Can Tortoise auto-update in these cases??!

El dia dilluns, 15 de març de 2021 a les 0:35:20 UTC+1, Kieren va escriure:

[Christopher White]

Another issue here, the update process doesn't allow you to omit externals. What I need to do is NOT update from the panel, update manually with omit externals, and then try again.

[Steve Wicinski]

Under v1.4.0 and before, Tortoise would normally merge with no issues multiple times (as stated above). If there were issues with the files, you'd get a dialog if you want to update, and if you said yes, it would update and then take you back to the commit screen to try the commit again. (This mirrors what you say).

However, with v1.4.1, there are two changes. One is that it tells you far more often that your 'out of date' even though you updated prior to the last commit (there should be no reason that I'm out of date). Far worse, though, is the fact Tortoise no longer (or at least very rarely, I had it work once out of some 20 or more tries) prompts you to update after telling you an update is needed. It tells you an update is needed, then just closes. This is what is aggravating. You (a) have to now manually update when before tortoise handled it for you), and (b) you now have to start up the merge process again, requiring you to make the selections again, hoping you get them the same. 

[Daniel Sahlberg]

onsdag 7 april 2021 kl. 01:21:30 UTC+2 skrev Steve Wicinski:

Under v1.4.0 and before, Tortoise would normally merge with no issues multiple times (as stated above). If there were issues with the files, you'd get a dialog if you want to update, and if you said yes, it would update and then take you back to the commit screen to try the commit again. (This mirrors what you say).

However, with v1.4.1, there are two changes. One is that it tells you far more often that your 'out of date' even though you updated prior to the last commit (there should be no reason that I'm out of date). Far worse, though, is the fact Tortoise no longer (or at least very rarely, I had it work once out of some 20 or more tries) prompts you to update after telling you an update is needed. It tells you an update is needed, then just closes. This is what is aggravating. You (a) have to now manually update when before tortoise handled it for you), and (b) you now have to start up the merge process again, requiring you to make the selections again, hoping you get them the same. 

Can you provide some steps to reproduce when TSVN tells you that an update is needed but then doesn't prompt to update? I think that is definately a bug. (I'm just saying that I have not run into it when testing this thread or IRL but I must admit that merging is seldom part of my workflow). If it can be demontrated with a reproduction reciept then someone can surely fix it.

Kind regards,

Daniel Sahlberg

[Kieren Robinson]

I get this every time I commit without the update prompt, and have to manually update then try again. Is this to do with the folder having merges from other tags to it stored? (noticed in diffs)

Thing is even if I had a prompt for it to update I'd still find it a problem as it still takes me over twice as long to do my merges now than before with how long updates take (they're quite large). Asking again if we could please have a setting to disable this check as it didn't seem needed before this, or maybe we just never encountered what it's meant to fix?

Thanks,

Kieren

[Dean Bailes]

So for now my solution is not to upgrade past 1.14.0.  Hopefully a sensible solution can be found.

[Dimas SC]

Yes, it's a shame 😡 It's frustrating how much time we waste "thanks" to this """""feature""""". Back to 1.14 or transtion to git.

El dia divendres, 11 de juny de 2021 a les 15:07:42 UTC+2, Dean Bailes va escriure:

[Stefan]

just use a nightly build.

[Kieren]

Yesssss, working good now. Thanks!

On Saturday, June 12, 2021 at 5:05:30 AM UTC+12 Stefan wrote:

just use a nightly build.

[Kieren]

Actually, seems like it might be happening a little less often but still a lot for me to be an annoyance on both branches and tags.

[Luca Petrini]

This issue as been solved?

I keep getting the "Cannot merge into mixed-revision working copy...try updating first" message before each merge on my branches; after updating the working copy, it works (with TortoiseSVN-1.14.1.29085).

[Kieren Robinson]

Still happening, has dramatically slowed down merges for our team and producers unfortunately.

Please either give us an option to disable this, change the prompt to a warning that can be skipped, or put it back how it was.

[Stefan]

[Kieren]

Ah my apologies. This works, cheers.

On Tuesday, May 3, 2022 at 4:34:58 AM UTC+12 Stefan wrote:

[Manuel Leithner]

Would it be possible to add an "Update" button to the merge failed dialog that starts an update and reopens the merge dialog with selected revisions again?

[Tim C]

> Would it be possible to add an "Update" button to the merge failed dialog that starts an update and reopens the merge dialog with selected revisions again?

+1, this would be very helpful

Also is it possible to set the default value of the 'Allow mixed revisions' checkbox in the Merge options dialog? In my use cases (cherry pick merges of several commits one after another) it is an extra step that I always forget to do and have to re-initiate merge (pick up the source branch again, re-select revisions etc.). It is time consuming and very annoying when it fails. An internal config variable (under Advanced page in Settings) would be sufficient.

Thank you.

[Daniel Sahlberg]

torsdag 20 juli 2023 kl. 03:11:10 UTC+2 skrev Tim C:

> Would it be possible to add an "Update" button to the merge failed dialog that starts an update and reopens the merge dialog with selected revisions again?

+1, this would be very helpful

There is already code to take care of this, see attachment. However it relies on the exact error returned from the Subversion library ("Cannot merge into mixed-revision working copy", or rather the specific error number 195020 used internally).

If there is a case where the merge produce an error but the Update needed dialog isn't show, please report how to reproduce it (preferably with a screenshot or copy of the error message) and we can probably catch that as well.

Also is it possible to set the default value of the 'Allow mixed revisions' checkbox in the Merge options dialog? In my use cases (cherry pick merges of several commits one after another) it is an extra step that I always forget to do and have 

to re-initiate merge (pick up the source branch again, re-select revisions etc.). It is time consuming and very annoying when it fails. An internal config variable (under Advanced page in Settings) would be sufficient.

I have added such an option in r29597, there will be a new advanced setting MergeAllowMixedRevisionsDefault controlling the default state of the "Allow mixed revisions (not recommended)" checkbox. Because of problems with the nightly builds, you currently need to build TSVN yourself if you want to test it.

I will one last time repeat what is written in the Subversion book about mixed-revision working copy merges:

[[[

Without going into too much detail, this is because of limitations in the way merges are tracked by the svn:mergeinfo property (see the section called “Mergeinfo and Previews” for details). These limitations mean that merges into mixed-revision working copies can result in unexpected text and tree conflicts.[34] We don't want any needless conflicts, so we update the working copy and then reattempt the merge.

]]]

Also re-posting the link provided by Stefan previously about one example of how to hit the described error: https://groups.google.com/g/tortoisesvn/c/cplTU-e_IU0/m/aW6M6kTmAwAJ

 

Anyhow, if your workflow works doing mixed-revision working copy merges, then feel free to set the new advanced setting.

Kind regards,

Daniel Sahlberg

[Manuel Leithner]

Hi,

I attached 3 screenshots of the merging and the following error.

Our svn repository setup looks like that

repository

    trunk/

    branches/patchBranch1_x

Repro:

1. Checkout both (trunk and the patch branch)
   1. D:\code\trunk
   2. D:\code\patchBranch1_x
2. Commit a file/fix in trunk
3. Start merge process on patch branch 
   1. Select revisions
   2. Don't change default merge options
   3. Click on merge
   4. see Merge Fail and no prompt window

[Stefan]

using your screenshot, just marking something:

[Daniel Sahlberg]

måndag 31 juli 2023 kl. 08:55:23 UTC+2 skrev Manuel Leithner:

[...]

Can't reproduce it unfortunately. When I click OK in the above dialog, I get the task dialog Command failed - Update needed with the choices to update or cancel.

(I'm now assuming you want to update the WC do to avoid doing a mixed-revision WC merge. If you want to do a mixed-revision WC merge, then you need to set the checkbox in Stefan's response.

Kind regards,

Daniel

[Manuel Leithner]

yes you are right. I don't want to perform a mixed version merge (that works - tested it multiple times).

But i don't get the Command failed dialog. Only option is to click on OK and then I will loose the whole merge info (selected revisions)

[Daniel Sahlberg]

måndag 31 juli 2023 kl. 11:28:47 UTC+2 skrev Manuel Leithner:

yes you are right. I don't want to perform a mixed version merge (that works - tested it multiple times).

But i don't get the Command failed dialog. Only option is to click on OK and then I will loose the whole merge info (selected revisions)

The Command failed dialog will appear after you click OK. I can't figure out why it doesn't...

Kind regards,

Daniel

[Manuel Leithner]

do you perform a specific merge (manually choosing the revisions) ? in your screenshot above it shows '"Auto-merge"

[Daniel Sahlberg]

tisdag 1 augusti 2023 kl. 12:13:06 UTC+2 skrev Tim C:

> There is already code to take care of this, see attachment.

Unfortunately this does not seem to work on my computer. Please see attached images. Nothing happens after I click 'OK' in the 'Merge Failed!' window. As you can see, I am merging specific revisions.

It seems the behaviour is different between merging all and cherrypicking specific revisions (as also noted by Manuel Leithner). Don't know why yet, but it should be fairly easy to figure out now that I can reproduce the issue.

I am using TortoiseSVN 1.14.5 (Build 29465 - 64 Bit , 2022/09/24 08:31:31). Has it been changed after that version was released?

The code was added long time ago, merging all revisions should work.

Kind regards,

Daniel Sahlberg

[Tim C]

Hi Daniel,

I have just installed the most recent nightly build, but cannot see the MergeAllowMixedRevisionsDefault setting. Please see screenshots. What am I doing wrong?

Thanks,

Tim

[Tim C]

The last line in Changelog.txt copied by the latest nightly build installer reads:

"- NEW: Added a menu item in Project monitor to check one specific project. (Daniel Sahlberg)"

So it seems that r29597 somehow did not make it to the nightly build, as it added another line to Changelog.txt after the one I have quoted.

[Daniel Sahlberg]

I suspect this is a problem on the nightly build server coming from the switch to Sourceforge. I've made a change to the build script which should hopefully bring it up to date again.

Kind regards,

Daniel

[Tim C]

Thanks Daniel. Unfortunately it does not seem to have helped -- the new build's changelog still ends with the same line.

[Daniel Sahlberg]

After some help from Cirata, who maintain the Nightly build server for us, it seems the nightly builds are back on track. The build of revision 29621, dated tonight, seems to contain the advanced setting. Unfortunately, there was also a previous build with the same revision that DIDN'T contain the setting so to be sure you have the correct build, wait until tomorrow when 29623 (or later) comes out.

Kind regards

Daniel

[Tim C]

Thanks Daniel. Working as advertised now. Really appreciate your help!

Regards,

Tim

[Dimas SC]

It works with the last version! If the merge fails, it automatically updates and re-executes the merge again. Thx !!!!

El dia divendres, 3 de novembre del 2023 a les 2:12:32 UTC+1, Tim C va escriure: