[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Bert Huijben <bert_at_qqmail.nl>
Date: Mon, 14 Sep 2015 12:03:46 +0200

> -----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:04:09 CEST

This is an archived mail posted to the Subversion Users mailing list.