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

Re: Possible bug in conflict resolver

From: Stefan Sperling <stsp_at_elego.de>
Date: Tue, 12 Mar 2019 16:04:56 +0100

On Tue, Mar 12, 2019 at 02:43:32PM +0000, Jonathan Guy wrote:
> Hi all
> Not sure if this is a bug or expected behaviour.
> Using Subversion 1.11.1
> Two people with separate checkouts working on the same file.
> Person A edits a line and the renames the file and commits.
> Person B edits the same line in the same file and then does an update.
> > The conflict resolver first flags the tree conflict which is resolved with a move and merge.
> The subsequent merge then produces the second conflict.
> Here’s were the behaviour is not what I expected. If I select “tf” so accepting all incoming changes I end up with a file that is resolved but is showing as modified. I check the contents and it contains my changes.
> Conversely if I resolve using “mf” so rejecting incoming changes I end up with a file that is resolved but is showing as normal and is identical to the head version and I have lost all my changes.
> I’m pretty sure this not the intended behaviour but I could be wrong.
> Regards
> Jonathan

Hi Jonathan,

Yes, this is a bug. The text merge performed by the resolver has the
'.new' and '.working' sides swapped. It works correctly during 'svn merge'
but not during 'svn update'.

I will try to fix this.

Received on 2019-03-12 16:13:57 CET

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