Improve Merge execution dialog

[Tobias Knauss]

When executing a merge, the last dialog is a (long) scrolling list of file names, showing which files have been merged.

If there are conflicts in the merge, the line of the respective file is shown in read.

After the merge has finished, the first red line is selected and the "Edit Text Conflicts" dialog is shown (in case of text files). This conflict dialog blocks access to the file list dialog, so I cannot scroll down and see the summary.

I don't even recall at the moment whether the summary tells about the number of merged files and, what I need, the number of conflicting files, but you cannot see it anyway since you cannot scroll down to the end as long as any of the conflict dialogs is shown.

Therefore, please make the following improvements:

1) if you click "abort" on the conflicts dialog, add a possibility to re-enable this dialog and the automatic sequence of showing that dialog for every conflicting file.

2) show the summary not only at the end of the file list, but also in an additional label underneath the file list control, see screenshot.

[Tobias Knauss]

After resolving all conflicts, a label appears: "Merged:8, Added:187, Deleted:61, Updated:531"

This information should be shown (and enhanced, and updated) directly after the auto-merge has finished and before showing the first conflict window.

The reason why I would like to have the above mentioned numbers: If I see "50 files with conflicts", then I can estimate how long it will take to resolve them. If I don't know that number, I don't know whether it makes sense to do that work today or leave the computer on and continue the next day. I actually was just about to go home when I finished the last file. So now I can commit and resolve the issue.

[Bruce C]

I agree that your suggestion would better fit my workflow too.

I'd go futher and suggest that I'd simply want to get to the merge summary first and review that before deciding whether I want to jump into the conflict resolution. I expect that the argument against this would be that the same result is achieved by simply cancelling the conflict resolution dialog. My issue with that is that it's non-obvious whether the Cancel button cancels the conflict resolution for all conflicted items or simply the first conflicted item. I believe it's the former but this isn't obvious (to me). This doesn't happen often (as I try to avoid these circumstances) so when it does, I tend not to remember exactly what the Cancel button does.

For me, I'd rather that the merge process simply displayed the merge result, even if there are conflicts, rather than auto-start the conflict resolution process. If I want to initiate conflict resolution, I can initiate that separately.

For backwards compatibility, perhaps this might be a merge dialog option.

[Tobias Knauss]

I agree to your enhanced suggestion. The conflict resolution process should not start automatically, but per button-click (there may be an option "start conflict resolution automatically" though).

That button would have the advantage that you could re-start the conflict resolution process after you have (accidentally) aborted it.

About the labelling of the "abort" button: since there is an option "Postpone" (equals "skip/cancel conflict resolution for this file"), the meaning of "abort" in my opinion is clear enough. But it can be improved by labelling it "abort conflict resolution process"; there's enough space for a wide button (or make it 40px high and use multiline text).

[Stefan]

On Monday, December 7, 2020 at 4:20:54 PM UTC+1 Tobias Knauss wrote:

Therefore, please make the following improvements:

1) if you click "abort" on the conflicts dialog, add a possibility to re-enable this dialog and the automatic sequence of showing that dialog for every conflicting file.

r29030

 

2) show the summary not only at the end of the file list, but also in an additional label underneath the file list control

r29031

 

[Tobias Knauss]

Works as expected. Very well, thank you!

[Tobias Knauss]

Well, not completely. I replied a little early. After clicking on Abort and reopening the resolve dialog, I can no longer choose "Accept incoming for conflicts". This gives an error message "Subversion reported an error: User cancelled."

Is this reported error from TSVN or from the SVN library? However, it means that you better don't allow reopening the resolve dialog until all functionality fully works in the reopened dialog.

[Stefan]

try r29039

[Tobias Knauss]

Stefan schrieb am Freitag, 11. Dezember 2020 um 19:28:24 UTC+1:

try r29039

Did you compile and test the changes yourself before you published them as a new nightly build? I don't want to be rude, but it just looks like you didn't.

I tested all options and found that each of them can be used again. However I did *not* take the time to test whether the chosen options are applied correctly, because I am confident that this part still works.

But I found other things that seem to be broken:

- The color of the conflicting lines used to turn green after a solution for a conflict was chosen. This is no longer the case, the color stays red.

- The status line does not update. After resolving all conflicts, it still says "conflicted:80, ..."

- "Jump to next conflict" is still shown and cycles through all lines of previously conflicting files.

So it looks like the entire GUI is not updated.

Another thing I found, which may be intended, but questionable: After aborting the merge conflict dialog and upon reopening it, the dialog is shown again for every item that was "postponed" in the first run. Since a user chose to postpone it on that run, I think he also would postpone it on the next run, because postponing actually is a solution that the user chose, they just did not resolve the conflict. Therefore in my opinion, the dialog should not  be shown again for postponed items, but others may think different about that. You might show a checkbox at the bottom of that dialog of at the bottom of the "merge finished" dialog, saying "retry solving merge conflicts on postponed items" to deal with both situations, but since I usually don't postpone items, I cannot tell about the need of such an option.

A minor suggestion for improvement on the merge conflict dialog at the end:

1) I would use slightly different labels: "Recect incoming for conflicts" instead of "Reject conflicts", along the lines of "Accept incoming for conflicts"

2) I don't see a relevant benefit of the clickable label "Jump to next conflict", since the "merge conflict" dialog starts at the first unresolved item in the list when (re)opened. I understand that users may want to go through the conflicts in that list, but then you should add the possibilty to open the "merge conflict" dialog on a specific file. The context menu of a conflicting file in the "merge finished" dialog currently shows "edit conflict", "mark as resolved", "resolve using mine", resolve using theirs". Either you could add "open 'merge conflict' dialog", or you could add the missing options from the merge conflict dialog: "accept incomfing for conflicts", "reject incoming for conflicts", ...

Regards

Tobias

[Stefan]

On Monday, December 14, 2020 at 10:46:57 AM UTC+1 Tobias Knauss wrote:

Stefan schrieb am Freitag, 11. Dezember 2020 um 19:28:24 UTC+1:

try r29039

Did you compile and test the changes yourself before you published them as a new nightly build? I don't want to be rude, but it just looks like you didn't.

Of course I did. But I can stop doing that any time.

 

I tested all options and found that each of them can be used again. However I did *not* take the time to test whether the chosen options are applied correctly, because I am confident that this part still works.

But I found other things that seem to be broken:

- The color of the conflicting lines used to turn green after a solution for a conflict was chosen. This is no longer the case, the color stays red.

- The status line does not update. After resolving all conflicts, it still says "conflicted:80, ..."

- "Jump to next conflict" is still shown and cycles through all lines of previously conflicting files.

So it looks like the entire GUI is not updated.

Sorry, forgot to enable the interacting resolving mode when re-starting the resolving.

 

[Tobias Knauss]

Stefan schrieb am Montag, 14. Dezember 2020 um 18:08:54 UTC+1:

On Monday, December 14, 2020 at 10:46:57 AM UTC+1 Tobias Knauss wrote:

Stefan schrieb am Freitag, 11. Dezember 2020 um 19:28:24 UTC+1:

try r29039

Did you compile and test the changes yourself before you published them as a new nightly build? I don't want to be rude, but it just looks like you didn't.

Of course I did. But I can stop doing that any time.

 

No, you should not stop testing, please enhance your testing instead.

I am happy about the new functionality, but it's a bit frustrating when testing on the user's end reveals different problems after each update. This, and your words "try ..." instead of your usual "solved in ..." made me think that you maybe did not have enough time for tests.

The updates and colours work again after reopening "merge conflicts", but I found that after reopening "merge conflicts", the dialog "fetching tree conflict information" does not show anymore or with delay, and is sometimes opened behind the "merge conflicts" dialog. It is shown in the taskbar, but cannot be brought into the foreground, so I also cannot click it's abort button on long-lasting operations. Right now it is in the foreground, but I cannot click "abort" anymore. And when clicking on the "merge conflicts" dialog, the "fetching tree conflicts" is in the background again and stays there.

Seems like that whole dialog does not react anymore, because even after selecting it by ALT+Tab, the space bar (which should click the abort button), does not work.

I tested all options and found that each of them can be used again. However I did *not* take the time to test whether the chosen options are applied correctly, because I am confident that this part still works.

But I found other things that seem to be broken:

- The color of the conflicting lines used to turn green after a solution for a conflict was chosen. This is no longer the case, the color stays red.

- The status line does not update. After resolving all conflicts, it still says "conflicted:80, ..."

- "Jump to next conflict" is still shown and cycles through all lines of previously conflicting files.

So it looks like the entire GUI is not updated.

Sorry, forgot to enable the interacting resolving mode when re-starting the resolving.

 

This part is working again, as written above.

[Tobias Knauss]

There seems to be a leftover bug in the merge summary dialog:

I just merged a branch and postponed all tree conflicts, because I wanted to check them at the end. After the guided resolution of conflicts has finished, I clicked on the new button "Resolve Conflicts" to reopen the conflict resolving, but then the whole dialog hanged and did not respond anymore. Looks like it's not able to reopen when only tree conflicts are left.

TortoiseSVN 1.14.99, Build 29042 - 64 Bit -dev, 2020/12/14 17:50:08

[Stefan]

fixed a bug in r29066 which would make the button retry the merge instead of solving the conflicts.

But a retry-merge should not make the dialog hang?

When I did that the merge immediately went through. But of course I'm using a small repo to test, maybe your merge is really big?