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 <bert_at_qqmail.nl> wrote:
>
>
> > -----Original Message-----
> > From: Stefan Hett [mailto:stefan_at_egosoft.com]
> > Sent: maandag 14 september 2015 09:54
> > To: users_at_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
>
>
>
Received on 2015-09-14 12:58:19 CEST