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,
Daniel Becroft <djcbecr...@gmail.com> writes:
> 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.
>
> On Mon, Sep 14, 2015 at 8:04 PM Bert Huijben <b...@qqmail.nl> wrote:
>
>>
>>
>> > -----Original Message-----
>> > From: Stefan Hett [mailto:ste...@egosoft.com]
>> > Sent: maandag 14 september 2015 09:54
>> > To: users@subversion.apache.org
>> > Subject: Re: 1.9 - Can't resolve to 'mine full' option for binary file
>> conflict
>> >
>> > 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.
>> > >
>> > > 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.
>> > 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).
>>
>> 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
>>
>>
>>
--
Philip Martin
WANdisco
