You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Jonathan Guy <jo...@ikoder.com> on 2019/03/12 14:43:32 UTC

Possible bug in conflict resolver

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

Re: Possible bug in conflict resolver

Posted by Stefan Sperling <st...@elego.de>.
On Tue, Mar 12, 2019 at 04:04:56PM +0100, Stefan Sperling wrote:
> 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.

Fixed in https://svn.apache.org/r1855419

I'll nominate this fix for backport to 1.10/1.11/1.12 now.

Re: Possible bug in conflict resolver

Posted by Stefan Sperling <st...@elego.de>.
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.

Thanks,
Stefan