1.9 - Can't resolve to 'mine full' option for binary file conflict

[Daniel Becroft]

Hi guys,

I've just upgraded to SVN 1.9. One of the first things I noticed is that when a binary file conflict is raised during an SVN update, I can no longer use the 'mine-full' option to resolve. 

The only options I have are: (r) working and (tf) theirs-full.

I can't use the 'r' (working) option, as I get a message of "Invalid option; use diff/edit/merge/launch before choosing 'mark resolved'. 

If I postpone, and try resolving afterwards, I get the following errors;

> svn resolve file.binary --accept mine-full

svn: warning: W155027: Conflict on 'file.binary' could not be resolved because the chosen version of the file is not available.

svn: E155027: Failure occurred resolving one or more conflicts

I can't find anything in the release notes about the removal of the 'mine-full' option on binary files. Was it intentional? If so, what's the intended workflow for resolution?

Current version:

svn, version 1.9.0-SlikSvn (SlikSvn/1.9.0)

   compiled Aug 26 2015, 17:09:55 on x86/x86_64-microsoft-windows6.2.9200

Cheers,

Daniel B.

[Stefan Hett]

Hi Daniel,

just to second ur observation:
I think I ran into the same problem last Thursday/Friday using TSVN
1.9.1. I didn't report it yet because I didn't check out whether it's a
TSVN or an SVN issue.
Using TSVN, it however also gives me the "file not found" error when I
try to resolve a binary conflict selecting "Use Repository version"
during the merge dialog.

I'm sure u are already ware, but just in case: My workaround was to let
the file in conflict and afterwards resolve the conflict by reverting
the file (so it was in the repository's state which I intended).

--
Regards,
Stefan Hett

[Bert Huijben]

In case of a binary file the original working copy version is left as the working version, whereas for text conflict the working copy version is changed into a mine version and a best effort merge is performed to the a new working copy version potentially containing conflict markers.

In this case you probably get the result you want by just choosing the working copy version. The Subversion developer responsible for choosing this UI determined that it didn't make much sense to offer two different resolve options with exactly the same result.

Bert

>
> --
> Regards,
> Stefan Hett

[Daniel Becroft]

Thanks, Bert. I understand the removal of "mine-full", and combining it with the "working" option. But, the issue is that there is no functional option that allows the user to select to keep the "working" (mine) version of the conflict. 

If I select (r) (accept the working version of the file), I get a validation error: "Invalid option; use diff/edit/merge/launch before choosing 'mark resolved".

The remaining three options (theirs-full, postpone and postpone all) either result in the conflict remaining, or data loss by removing the working file altogether.

[Philip Martin]

Indeed there is a bug:

svnadmin create repo
svnmucc -mm -U file://`pwd`/repo put repo/format f propset svn:mime-type application/octet f
svnmucc -mm -U file://`pwd`/repo put repo/db/format f
svn co file://`pwd`/repo@1 wc
echo xx > wc/f
svn up wc

The initial conflict prompt offers:

Conflict discovered in binary file 'wc/f'.
Select: (p) postpone, (tf) their version, (s) show all options:

Trying (s) offers:

(r) - accept the working copy version of file [working]
(tf) - accept the incoming version of file [theirs-full]
(p) - mark the conflict to be resolved later [postpone]
(q) - postpone all remaining conflicts
(s) - show this list (also 'h', '?')
Words in square brackets are the corresponding --accept option arguments.

Select: (p) postpone, (tf) their version, (s) show all options:

Trying (r) gives:

Invalid option; use diff/edit/merge/launch before choosing 'mark resolved'.

but one cannot use those options for a binary file.

Perhaps we need something like this:

Index: ../src/subversion/svn/conflict-callbacks.c
===================================================================
--- ../src/subversion/svn/conflict-callbacks.c (revision 1702397)
+++ ../src/subversion/svn/conflict-callbacks.c (working copy)
@@ -1013,7 +1013,7 @@
the file if they've edited it, or at least looked at
the diff. */
if (opt->choice == svn_wc_conflict_choose_merged
- && ! knows_something)
+ && ! knows_something && ! is_binary)
{
SVN_ERR(svn_cmdline_fprintf(
stderr, iterpool,

or perhaps this:

Index: ../src/subversion/svn/conflict-callbacks.c
===================================================================
--- ../src/subversion/svn/conflict-callbacks.c (revision 1702397)
+++ ../src/subversion/svn/conflict-callbacks.c (working copy)
@@ -1013,7 +1013,7 @@
the file if they've edited it, or at least looked at
the diff. */
if (opt->choice == svn_wc_conflict_choose_merged
- && ! knows_something)
+ && ! knows_something && diff_allowed)
{
SVN_ERR(svn_cmdline_fprintf(
stderr, iterpool,

--
Philip Martin
WANdisco

[Philip Martin]

Philip Martin <philip...@wandisco.com> writes:

> or perhaps this:
>
> Index: ../src/subversion/svn/conflict-callbacks.c
> ===================================================================
> --- ../src/subversion/svn/conflict-callbacks.c (revision 1702397)
> +++ ../src/subversion/svn/conflict-callbacks.c (working copy)
> @@ -1013,7 +1013,7 @@
> the file if they've edited it, or at least looked at
> the diff. */
> if (opt->choice == svn_wc_conflict_choose_merged
> - && ! knows_something)
> + && ! knows_something && diff_allowed)
> {
> SVN_ERR(svn_cmdline_fprintf(
> stderr, iterpool,
>
>

That allows 'r' to work, but if 'r' is going to be allowed it should
probably be shown by the first prompt, so perhaps:

Index: ../src/subversion/svn/conflict-callbacks.c
===================================================================
--- ../src/subversion/svn/conflict-callbacks.c (revision 1702397)
+++ ../src/subversion/svn/conflict-callbacks.c (working copy)

@@ -796,7 +796,7 @@
}
else
{
- if (knows_something)
+ if (knows_something || is_binary)
*next_option++ = "r";

/* The 'mine-full' option selects the ".mine" file so only offer

@@ -1013,7 +1013,7 @@
the file if they've edited it, or at least looked at
the diff. */
if (opt->choice == svn_wc_conflict_choose_merged
- && ! knows_something)
+ && ! knows_something && diff_allowed)
{
SVN_ERR(svn_cmdline_fprintf(
stderr, iterpool,

--
Philip Martin
WANdisco

[Stefan Sperling]

On Mon, Sep 14, 2015 at 12:27:44PM +0100, Philip Martin wrote:
> Index: ../src/subversion/svn/conflict-callbacks.c
> ===================================================================
> --- ../src/subversion/svn/conflict-callbacks.c (revision 1702397)
> +++ ../src/subversion/svn/conflict-callbacks.c (working copy)
> @@ -796,7 +796,7 @@
> }
> else
> {
> - if (knows_something)
> + if (knows_something || is_binary)
> *next_option++ = "r";
>
> /* The 'mine-full' option selects the ".mine" file so only offer
> @@ -1013,7 +1013,7 @@
> the file if they've edited it, or at least looked at
> the diff. */
> if (opt->choice == svn_wc_conflict_choose_merged
> - && ! knows_something)
> + && ! knows_something && diff_allowed)
> {
> SVN_ERR(svn_cmdline_fprintf(
> stderr, iterpool,
>
>

I agree.

And thanks for mopping up after me ;-)
I believe I accidentally broke this in r1667692.

[Pete Harlan]

On Mon, Sep 14, 2015 at 3:03 AM, Bert Huijben <be...@qqmail.nl> wrote:
>> On 9/14/2015 7:56 AM, Daniel Becroft wrote:
>> > Hi guys,
>> >
>> >
>> > I've just upgraded to SVN 1.9. One of the first things I noticed is
>> > that when a binary file conflict is raised during an SVN update, I can
>> > no longer use the 'mine-full' option to resolve.
>> >
>> > The only options I have are: (r) working and (tf) theirs-full.

...

> The Subversion developer responsible for choosing this UI determined that it
> didn't make much sense to offer two different resolve options with exactly the
> same result.

Perhaps a user or script wants to resolve a merge of some files in
favor of their versions, regardless of whether the file is binary.

You're now requiring that user or script to consider binary-ness in
order to use the UI, no?

--Pete